主な変更点
■ 追加・変更された機能
● NDB Cluster API：NDBで使用されるNode.jsのバージョンが12.20.1にアップグレードされました。（バグ #32356419） ● ndbinfo情報データベース：dict_obj_treeテーブルをndbinfo情報データベースに追加しました。このテーブルは、dict_obj_infoテーブルに表示されるものと同様のNDBデータベースオブジェクトに関する情報を提供しますが、次のようなオブジェクト間の関係の表示を簡素化する階層的またはツリーのような方法で表示します：テーブルとインデックス、テーブルスペースとデータファイル、ログファイルグループとUNDOログファイル。 列aにプライマリキーがあり、列bに一意のキーがあるテーブルt1を表示する例を次に示します。 mysql> SELECT indented_name FROM ndbinfo.dict_obj_tree -> WHERE root_name = 'test/def/t1'; +----------------------------+ | indented_name | +----------------------------+ | test/def/t1 | | -> sys/def/13/b | | -> NDB$INDEX_15_CUSTOM | | -> sys/def/13/b$unique | | -> NDB$INDEX_16_UI | | -> sys/def/13/PRIMARY | | -> NDB$INDEX_14_CUSTOM | +----------------------------+ 7 rows in set (0.15 sec) （バグ #32198754） ● ndbinfo情報データベース：backup_idテーブルをndbinfo情報データベースに追加しました。このテーブルには、単一の列（id）と単一の行が含まれており、その列の値は、ndb_mgmクライアントで取得されたクラスタの最新のバックアップのバックアップIDです。NDBバックアップが見つからない場合、その値は0です。 このテーブルから選択すると、ndb_select_allユーティリティを使用してこの情報を取得するプロセスが置き換えられ、内部SYSTAB_0テーブルの内容がダンプされます。これは、エラーが発生しやすく、完了するまでに非常に長い時間がかかる可能性があります。（バグ #32073640） ● クラスタで使用されている現在の設定の世代番号を示すステータス変数Ndb_config_generationが追加されました。これは、クラスタの設定が変更されたかどうかを判別するためのインジケーターとして使用できます。（バグ #32247424） ● NDB Clusterは、MySQL host_application_signalコンポーネントサービスを使用してSQLノードのシャットダウンを実行するようになりました。（バグ #30535835、バグ #32004109） ● NDBは、インデックス統計の計算に次の2つの改善を実装しました。 ・以前は、インデックス統計が単一のフラグメントからのみ収集されていました。これは、追加のフラグメントがこれらに使用されるように変更されます。 ・結果が破棄される行が非常に少ないテーブルなど、非常に小さいテーブルに使用されるアルゴリズムが改善されました。そのため、このようなテーブルの見積もりは以前よりも正確になるはずです。 ● 多くのNDB Clusterプログラムは、標準入力からのNDBバックアップを暗号化または復号化するためのパスワードの入力をサポートするようになりました。影響を受ける各プログラムに関連する変更は、次のとおりです。 ・ndb_restoreの場合、このリリースで導入された--backup-password-from-stdinオプションを使用すると、mysqlクライアントの--passwordオプションと同様に、安全な方法でパスワードを入力できます。このオプションを--decryptオプションと一緒に使用します。 ・ndb_print_backup_fileは、既存の-Pオプションの長い形式として--backup-password-from-stdinもサポートするようになりました。 ・ndb_mgmの場合、--backup-password-from-stdinは、システムシェルから暗号化されたクラスタバックアップを開始するための--execute "START BACKUP [options]"とともにサポートされ、同様の効果を持ちます。 ・ndbxfrmの2つのオプション、--encrypt-password-from-stdinと--decrypt-password-from-stdinは、このリリースにも導入されており、このプログラムの使用時にはそれぞれ同様の動作をし、バックアップファイルを暗号化または復号化します。 さらに、--encrypt-backupでndb_mgmを開始することにより、ndb_mgmがバックアップを作成する時はいつもndb_mgmに暗号化を使用させることができます。この場合、何も指定されていない場合、ユーザーはSTART BACKUPを呼び出す時にパスワードの入力を求められます。このオプションは、my.cnfファイルの[ndb_mgm]セクションでも指定できます。 また、ndb_mgm管理クライアントのSTART BACKUPの動作と構文がわずかに変更され、PASSWORDを指定せずにENCRYPTオプションを使用できるようになりました。現在、ユーザーがこれを行うと、管理クライアントはユーザーにパスワードの入力を求めます。
■ バグ修正
● パッケージング：mysql-cluster-community-server-debugおよびmysql-cluster-commercial-server-debug RPMパッケージは、mysql-cluster-community-serverおよびmysql-cluster-commercial-serverではなく、それぞれmysql-community-serverおよびmysql-commercial-serverに依存していました。（バグ #32683923） ● パッケージング：ファイルがサーバーRPMからクライアントプラグインRPMに移動されたため、NDB 7.6.15から8.0.22へのRPMアップグレードは成功しませんでした。（バグ #32208337） ● Linux：Linuxシステムでは、NDBは、/proc/meminfoから取得したメモリサイズを、キロバイトではなくバイト単位で提供されていると解釈していました。（バグ #102505、バグ #32474829） ● Microsoft Windows：Microsoft Visual Studio 2019を使用してWindowsでNDB Clusterを構築する時に生成されたいくつかの警告を削除しました。（バグ #32107056） ● Microsoft Windows：ndb_init()を使用してNDBライブラリを初期化すると、WindowsでNDBはFailed to find CPU in CPU groupいうエラーで正しく起動でませんでした。 この問題は、CPUへのプロセスの割り当てに関してWindowsがどのように機能するかが原因でした。マシンに64を超える論理CPUがある場合、Windowsは起動時にそれらを様々なプロセッサグループに分割します。各プロセッサグループは、最大64個のCPUを保持できます。デフォルトでは、プロセスは1つのプロセッサグループにのみ割り当てることができます。関数std::thread::hardware_concurrency()はマシン上の論理CPUの最大数を取得するために使用されましたが、Windowsでは、この関数は、現在のプロセスが関連するプロセッサグループに存在する論理CPUの最大数のみを返します。この値は、マシン上の各CPUに関するハードウェア情報を保持する配列にメモリを割り当てるために使用されます。配列はたった1つのプロセッサグループからのCPUに対して有効なメモリを保持していたため、別のプロセッサグループのCPUに関するハードウェア情報を保存および取得しようとすると、配列にバインドされた読み取り／書き込みエラーが発生し、メモリの破損や最終的にはプロセス障害が発生しました。 以前に参照されたhardware_concurrency()関数の代わりにGetActiveProcessorCount()を使用することで修正されました。（バグ #101347、バグ #32074703） ● Solaris：暗号化されたバックアップを処理するためにNDBFSを準備している間、O_DIRECTのアクティブ化は、ファイルの初期化の完了後まで中断されました。これにより、ext3ファイルシステムでハードディスクドライブを使用しているシステムで、REDOログファイルの初期化が過度の時間を必要としました。 Solarisでは、O_DIRECTの代わりにdirectioが使用されます。ファイルの初期化の前にdirectioをアクティブにすると、UFSファイルシステムでハードディスクドライブを使用する時に必要とされる時間が大幅に増加しました。 現在は、確実に、O_DIRECTを持つシステムでは、これはファイルの初期化の前にアクティブ化され、Solarisでは、directioはファイルの初期化後も引き続きアクティブ化されるようにします。（バグ #32187942） ● NDB Cluster APIs：ソースに含まれているいくつかのNDB APIコーディング例では、割り当てられた全てのリソースが解放されませんでした。（バグ #31987735） ● NDB Cluster APIs：NDBの一部の内部ディクショナリオブジェクトは、Ndbオブジェクトのデータベース名に依存する内部名前形式を使用しました。この依存関係は、必要であればより明確になり、それ以外の場合は削除されました。 NDB APIのユーザーは、Dictionary::listObjects()へのfullQualified引数が、falseとして指定すると、返されるリスト内のオブジェクトが完全修飾名を使用するというように機能することに注意する必要があります。（バグ #31924949） ● ndbinfo情報データベース：システム変数ndbinfo_databaseおよびndbinfo_table_prefixは、読み取り専用であることが意図されています。これらのいずれかまたは両方に対応するmysqldコマンドラインオプションを設定できることがわかりました。これを行うと、ndbinfoデータベースが誤動作しました。この修正により、mysqlクライアントでまたはコマンドラインからこれらの変数のいずれかを設定できなくなります。（バグ #23583256） ● NDB_STORED_USER権限を持つユーザーに影響を与えるクエリが、書き換えられずにMySQLサーバーログに出力される可能性がある場合がありました。現在、このようなクエリは省略または書き換えられ、キーワードIDENTIFIEDに続くテキストが削除されます。（バグ #32541096） ● SpinMethodデータノード設定パラメータに設定された値が無視されました。（バグ #32478388） ● コンパイル時のデバッグフラグDEBUG_FRAGMENT_LOCKはデフォルトで有効になっていました。これにより、リリースビルドの場合でも、DBLQHによるリソース使用量が増加しました。 これは、デフォルトでDEBUG_FRAGMENT_LOCKを無効にすることで修正されています。（バグ #32459625） ● ndb_mgmdは、管理クライアントのSHUTDOWNコマンドの後に行うのと同じように、SIGTERMが発生した場合に正常に終了するようになりました。（バグ #32446105） ● すでに使用されているポートで開始した場合、WindowsプラットフォームでSO_REUSEADDRを使用すると複数のソケットが同じアドレスとポートにバインドできるため、ndb_mgmdはエラーをスローしませんでした。 この問題に対処するために、SO_REUSEADDRPORTをSO_EXCLUSIVEADDRUSEに置き換えることで、すでに使用されているポートの再利用を防ぎます。（バグ #32433002） ● クラスタの最初のシステム再起動の検出でエラーが発生すると、SQLノードが途中で終了しました。（バグ #32424580） ● ジョブバッファフルの問題のto引数とfrom引数について報告された値が逆になりました。（バグ #32413686） ● 状況によっては、CPUの一時停止の時間を測定しようとすると、経過時間がゼロになる可能性がありました。さらに、非常に高速なスピン（例えば、100ns未満で100ループ）の平均を計算すると、ナノ秒がゼロになる可能性がありました。どちらの場合も、これにより、スピンキャリブレーションアルゴリズムがゼロ除算のために算術例外をスローしました。 平均スピン時間を計算する時にゼロ値を無視するようにアルゴリズムを変更することで、両方の問題を修正します。（バグ #32413458） 参照：バグ #32497174。 ● 内部メソッドNdb_rep_tab_reader::scan_candidates()が、ndb_replicationテーブル内の特定のデータベース、テーブル、またはサーバーIDにあいまいな一致を検出した場合、mysqldエラーログに書き込まれるメッセージでテーブル名とデータベース名が正しくフォーマットされませんでした。（バグ #32393245） ● ネストされたプッシュ結合を使用する一部のクエリは、正しく処理されませんでした。（バグ #32354817） ● ndb_mgmdはノードIDを割り当てる時、その設定を読み取って適切なIDを見つけ、ミューテックスはホスト名ルックアップの実行中保持されます。ネットワークアドレスの解決には長い時間がかかる可能性があるため、ネットワーク操作の実行中にこのようなミューテックスまたはロックを保持することは適切な方法とは見なされません。 この問題は、ミューテックスを保持しながら設定済みノードのリストを作成し、そのリストを使用してホスト名の照合やその他のロジックを実行することで修正されます。（バグ #32294679） ● スキーマ配布参加者は、ndb_schema_resultテーブルに応答を書き込んだ後、グローバルチェックポイントを開始できませんでした。これにより、コーディネーターが参加者からの結果を通知するイベントを受信するまでに不要な遅延が発生しました。（バグ #32284873） ● ndb_mgmdで使用されるグローバルDNSキャッシュにより、新しいIPアドレスを使用して新しいマシンでノードを再起動する時に、古いルックアップが発生しました。これは、ノードがノードIDを割り当てることができなかったことを意味します。 この問題は、次の変更によって対処されます。 ・ノードIDの割り当てはLocalDnsCacheに依存しなくなりました。 ・DnsCacheはローカルスコープのみを使用するようになりました。 （バグ #32264914） ● ndb_restoreは、不明な引数または無効な引数で開始された時にコアファイルを生成しました。（バグ #32257374） ● 自動同期は、NDBディクショナリにモック外部キーテーブルの存在を検出し、MySQLサーバーのデータディクショナリにそれらを再作成しようとしましたが、これらはNDBディクショナリの内部に留まり、MySQLサーバーに公開されないようにする必要があります。この問題を修正するために、NDB Clusterの自動同期メカニズムがそのようなモックテーブルを無視するようにしました。（バグ #32245636） ● クラスタ設定データの処理に関連するリソース使用量を改善しました。（バグ #32224672） ● 接続時にクライアントのバージョン番号を示すndb_mgmdから、残ったデバッグプリントアウトを削除しました。（バグ #32210216） 参照：この問題は、バグ #30599413のリグレッションです。 ● インデックスアクセス方式で（ファイルソートなしで）ORDER BYを使用してプッシュダウン結合からソートされた結果を取得している時に、SQLノードが予期せず終了することがありました。（バグ #32203548） ● REDOログの初期化のロギングは、ログパーツ番号ではなくログパーツインデックスを表示しました。（バグ #32200635） ● 拡張信号メモリを一時ストレージとして使用したため、信号データが上書きされました（そして失われました）。現在、このような場合、拡張信号メモリはこの方法では使用されません。（バグ #32195561） ● ClassicFragmentation = 1の場合、 ノードあたりのデフォルトのパーティション数（ndb_desc出力にPartitionCountとして表示）は、単一のライブノードで使用されるLDMスレッドの最小数を使用して計算され、データノードがクラスタを離れたりクラスタに参加した後（LDMスレッド数が変更された新しい設定を持つ可能性や、デフォルトのパーティション数が変更される可能性がある）でも、1回だけ実行されました。現在は、 このような場合、データノードがクラスタに参加またはクラスタを離れる度に、ノードあたりのデフォルトのパーティション数が再計算されます。 これは、ClassicFragmentationが0に設定されている場合、NDB 8.0.23以降では問題ではありません。（バグ #32183985） ● 内部関数Ndb_ReloadHWInfo()は、ホスト上の全てのCPUのハードウェア情報を更新する役割を果たします。レベル3キャッシュ情報を持たないLinux ARMプラットフォームの場合、これによりL3キャッシュIDにソケットIDが割り当てられましたが、共有L3キャッシュに接続されたCPUのリストを作成する時に必要なグローバル変数num_shared_l3_cachesの値を記録できませんでした。（バグ #32180383） ● 同じホスト上で同じポート番号を使用して2つの管理ノードを実行しようとした場合、それらが起動しなかった理由が必ずしもユーザーに明確ではありませんでした。このような場合、エラーログにメッセージを書き込むだけでなく、エラーメッセージSame port number is specified for management nodes node_id1 and node_id2 (or) they both are using the default port number on same host host_nameもコンソールに書き込まれ、問題の原因がすぐに明らかになります。（バグ #32175157） ● デフォルトのグループサフィックスを上書きするための内部テストで使用するために、ndb_mgmdおよびndb_configに--cluster-config-suffixオプションを追加しました。（バグ #32157276） ● 設定内の一部のホスト名が解決されず、クライアントがホスト名が解決されたホストから接続されたノードIDをエラーCould not alloc node id at <host>:<port>: Connection with id X done from wrong host ip 127.0.0.1, expected <unresolvable_host> (lookup failed)でループバックアドレスに割り当てようとした場合、管理サーバーはホスト名の一致に対して誤ったステータスを返しました。 これにより、接続しているクライアントがノードIDの割り当てに失敗しました。 この問題は、要求元のクライアントアドレスが設定済みのホスト名とどのように一致すべきかに関する全てのロジックを含むように、また、設定済みのホスト名が解決され得るかどうかを最初に確認するように、内部のmatch_hostname()関数を書き直すことにより修正されます。そうでない場合は、クライアントがノードIDの割り当てを再試行できることを示すエラーを受け取るように、特別なエラーが返されます。新しいエラーは、Could not alloc node id at <host>:<port>: No configured host found of node type <type> for connection from ip 127.0.0.1. Some hostnames are currently unresolvable. Can be retriedです。（バグ #32136993） ● ndb_setsockopt()の呼び出しが失敗した時に、内部関数ndb_socket_create_dual_stack()が新しく作成されたソケットを閉じませんでした。（バグ #32105957） ● ローカルチェックポイント（LCP）メカニズムがNDB 7.6で変更され、アイドル状態のフラグメント、つまり、最後のLCP以降変更されていないためにディスク上のメタデータの更新を必要としないフラグメントも検出されました。LCPメカニズムは、すぐに次のフラグメントの処理に進むことができました。このようなアイドル状態のフラグメントが非常に多い場合、これらをループするだけで必要なCPU消費が非常に大きくなり、ユーザートランザクションの遅延スパイクが発生しました。 このようなアイドル状態のフラグメントが処理される間には1ミリ秒の遅延がすでに挿入されました。後でテストしたところ、これは間隔が短すぎることがわかり、私たちは通常、以前に信じていたほど、これらのアイドル状態のフラグメントを完了するのに急いでいません。 この修正により、LCPを完了する緊急の必要性を示すREDOアラートがない場合、アイドル状態のフラグメントの遅延時間が20ミリ秒に延ばされます。REDOアラート状態が低い場合は、代わりに5ミリ秒待機し、アラート状態が高い場合は、1ミリ秒の遅延にフォールバックします。（バグ #32068551） 参照：バグ #31655158、バグ #31613158。 ● NDBテーブルが作成される時、それはグローバルディクショナリキャッシュで無効にされましたが、これは不要でした。さらに、グローバルディクショナリキャッシュに存在するテーブルを持つことは、NDBへのラウンドトリップを実行せずにテーブルキャッシュで見つけることができるため、実際には新しいテーブルを後で使用する場合に有利です。（バグ #32047456） ● ndb_mgmdプロセスがすでに使用されているポートのPortNumberを使用して開始しようとした時に、明確なエラーメッセージが提供されませんでした。（バグ #32045786） ● NDBがテーブルを閉じた時に、2つの問題が発生しました。 ・NDBは、FLUSH TABLESからクローズがいつ行われたかを検出できませんでした。これは、グローバルディクショナリキャッシュ内のNDBテーブル定義が無効化されなかったことを意味します。 ・以前にNDBを使用していなかったスレッドによってクローズが行われた時（例えば、FLUSH TABLESまたはRESET MASTERがテーブル定義キャッシュに保持されているha_ndbclusterのインスタンスを閉じた場合）、新しいThd_ndbオブジェクトが割り当てられました。 割り当てが失敗した場合にグローバルNdbオブジェクトへのフォールバックがありますが、そのような場合には発生せず、 したがって、すでに提供されているグローバルオブジェクトを使用するだけで無駄が少なくなります。 （バグ #32018394、バグ #32357856） ● NdbDictionaryImplの未使用の関数の引数に関連する多数のコンパイラ警告を削除しました。（バグ #31960757） ● 内部エラーコードをチェックする時に、不要なキャストが実行されました。（バグ #31930166） ● NDBは、実際にはこれらの操作にファイルを使用するようになったにもかかわらず、DDLを開いたり実行したりするテーブルの名前を決定するためにファイルシステムパスを使用し続けました。これは、文字セット間の不要な変換、MySQL固有のファイルシステムエンコーディングの処理、および解析を必要としました。さらに、これらの操作の結果は固定サイズのバッファに保存され、各インスタンスは数百バイトのメモリを不必要に使用しました。使用するデータベース名とテーブル名は、他の方法でNDBですでに利用可能であるため、ほとんどの場合、この変換は削除される可能性があります（削除されています）。（バグ #31846478） ● NDBオブジェクト数に関連する内部統計の生成は、解放されたNDBオブジェクトの過剰な数を返すことによって引き起こされる、1秒あたりのトランザクションの非常に高いレートでのトランザクション待ち時間の増加につながることがわかりました。（バグ #31790329） ● NDBは、バイナリログスレッドのシャットダウンおよび再起動中に、分散ユーザー（つまり、NDB_STORED_USER権限を持つユーザー）の許可を変更しようとした時に、予期しない動作をしました。この問題に対処するために、配布が成功しない時はいつも、ユーザーが明確な警告Could not distribute ACL change to other MySQL serversを受け取るようにします。この修正により、mysqldログメッセージの数も改善されます。（バグ #31680765） ● ndb_restoreで、blob値を削除したバックアップログの再生中に断続的なエラーが発生しました。これは、blobの1つ以上の値を含むメインテーブル行が削除された時にblobパーツが削除されたことが原因でした。これは、blobの削除に非同期APIを使用するようにndb_restoreを変更することで修正されます。これは、（同期APIとは異なり）blobメインテーブル行が削除された時にblobパーツの削除をトリガーしないため、メインテーブルのログ削除イベントはメインテーブルから行のみを削除します。（バグ #31546136） ● 以前のリリースからNDB Cluster 8.0にアップグレードすると、スキーマ配布メカニズムにアップグレードが含まれます。その一部として、ndb_schemaテーブルは、クラスタに接続されている全てのMySQLサーバーにバイナリログインジェクタースレッドを再起動させる方法で削除され再作成されます。これにより、ギャップイベントがバイナリログに書き込まれます。スレッドの再起動は全てのMySQLサーバーで同時に発生するため、スキーマ配布機能のアップグレードが実行された期間にまたがるバイナリログがなく、NDB Clusterのレプリケーションが中断されます。 この問題は、インジェクタースレッドがクラスタからの変更の処理を続行できるようにしながら、スキーマ分散テーブルを適切に再構成するためのサポートを追加することで修正されています。これは、DROP TABLEのDDLイベント通知を処理してスキーマ配布のサポートを一時的にオフにし、テーブルを再作成するための定期的なチェックを開始することによって実装されます。テーブルが再度正常に作成されると、通常のチェックがオフになり、スキーマ配布のサポートが再びオンになります。 さらに、スキーマ配布のアップグレードを実行するために必要な最小バージョンが8.0.24に引き上げられました。これにより、接続されている全てのAPIノードが新しいアップグレード手順をサポートするまで、スキーマ配布のアップグレードが自動的にトリガーされません。（バグ #30877233） 参照：バグ #30876990。 ● テーブル作成スキーマトランザクションが準備されると、テーブルはTS_CREATING状態になり、スキーマトランザクションがDBDIHブロックでコミットされるとTS_ACTIVE状態に変更されます。スキーマトランザクションのコミット中にDBDIHコーディネーターとして機能するノードに障害が発生した場合、別のノードがコーディネーターの引き継ぎを開始します。このノード障害を処理する時は、次のアクションが実行されます。 ・DBDICTが、テーブル作成スキーマトランザクションをロールフォワードしてコミットします。その結果、テーブルはTS_ACTIVE状態に変更されます。 ・DBDIHは、障害が発生したノード上のアクティブなテーブルレプリカを格納されているフラグメントレプリカのリストから別のリストに移動することにより、障害が発生したノードをテーブルから削除し始めます。 これらのアクションは非同期で何度も実行され、インターリーブすると競合状態が発生する可能性があります。その結果、障害が発生したノードのレプリカが存在するレプリカリストは、非決定的になり、リカバリ中のノード（つまり、新しいコーディネーター）と他のDIH参加ノードの間で異なる場合があります。この違いは、障害発生ノードのレプリカが、他の参加者での障害発生ノードのリカバリ中に、どのリストにあるかを知るための要件に違反していました。 これを修正するために、アクティブなテーブルレプリカの移動は、TS_ACTIVE状態のテーブルだけでなく、TS_CREATING（準備済み）状態のテーブルもカバーするようになりました。これは、準備済みスキーマトランザクションが常にロールフォワードされるためです。 さらに、中止されているテーブル作成スキーマトランザクションの状態がTS_CREATINGまたはTS_IDLEからTS_DROPPINGに変更され、そこでの競合状態が回避されるようになりました。（バグ #30521812） ● START BACKUP SNAPSHOTSTART WAIT STARTEDは、ユーザーの観点から、バックアップの復元ポイントの前にユーザーに制御を戻す可能性がありました。つまり、バックアップ開始通知は、同期グローバルチェックポイント（GCP）境界を待機する前に送信されました。これは、通知の受信後にコミットされたトランザクションが復元されたデータに含まれる可能性があることを意味しました。 この問題を修正するために、START BACKUPは、GCPが実際に開始された後にのみ、バックアップが開始されたという通知をクライアントに送信するようになりました。（バグ #29344262） ● GCC 6でNDBをビルドしようとした時に発見された多くの問題を修正しました（バグ #25038373） ● LDMごとに複数のログパーツを使用する時、REDOログの使用状況に基づくREDOアラート状態の計算は過度に積極的であったため、正しくありませんでした。
MySQL NDB Cluster 8.0.24リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-24.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。