MySQL NDB Cluster 8.3.0 Innovationリリース（リリース日：2024年1月16日） | MySQLのチューニング・保守サポート・コンサルティングの株式会社スマートスタイル　

コンパイル関連

NDB Cluster API: MySQL 8.0以降では、C++コンパイラを使用してMGM APIアプリケーションを構築する必要がありました。さらに、NDB APIアプリケーションとMGM APIアプリケーションの両方のコンパイラ要件は、NDB Clusterリリース間で一貫していませんでした。この修正により、次のように両方の問題が解決されます：
- MGM APIアプリケーションには、C99以降をサポートするCコンパイラが必要になりました。
- NDB APIアプリケーションには、C++11以降をサポートするコンパイラが必要になりました。
APIの将来のバージョンが引き続きこれらの要件を満たしていることを確認するために、リリース前テストも改善されました。
NDBの以前のバージョンのものも含め、NDB Cluster APIアプリケーションを構築するための言語サポートとコンパイラ要件の詳細については、General Requirementsを参照してください。（WL #15908）
NDB Clusterは、Ubuntu 23.10で正しくコンパイルされませんでした。（バグ #35847193）
s390xプラットフォーム用のNDB Clusterを構築できるようになりました。
（バグ #110807、バグ #35330936）

追加または変更された機能

このリリースでは、接続を認証および暗号化するためにトランスポート層セキュリティ（TLS）とインターネット公開鍵基盤（PKI）によって保護されたNDBノード間のネットワーク通信、および、NDB管理サーバーとそのクライアント間のネットワーク通信のサポートが実装されています。TLSは、NDB Transporter ProtocolとNDB Management Protocolの両方に適用されます。どちらの場合も、これはTLS相互認証を使用して行われます。
（MySQLクライアントプロトコルを使用する接続では、TLSを使用できるMySQLユーザー認証が採用されています。詳細については、Using Encrypted Connectionsを参照してください。）
新しいツール ndb_sign_keysを使用して、CA、証明書ファイル、キーを作成および管理できます。ndb_sign_keys --create-keyを使用して、クラスター内の全てのノードのキーと証明書のセットを生成できます。
秘密キーは適切な場所に作成されるため、秘密キーを含むファイルのコピーは最小限に抑えられます。秘密キーと証明書は両方とも、アクティブまたは保留中のいずれかとしてラベル付けされます。ndb_sign_keysは、アクティブなキーが期限切れになる前に保留中のキーでアクティブなキーを置き換えることができるように、キーをローテーションするためのヘルプも提供します。
ノードのTLS接続は、ndb_mgm --test-tlsを使用してテストするか、ndb_mgmクライアント内からTLS INFOコマンドを使用してテストできます。ndbinfo certificatesテーブルを確認して、クラスターノードで使用される証明書に関する情報を取得することもできます。
適切なクライアントオプションとノード設定パラメータを設定することにより、クラスターにTLSの要件を強制できます。詳細については、Using TLS Connectionsを参照してください。
TLS接続の使用は、NDB Cluster APIアプリケーションでもサポートされるようになりました。MGM AP サポートの詳細については、TLS Functionsを参照してください。NDB APIは、クライアントによるTLS接続を設定するためのNdb_cluster_connectionのconfigure_tls() get_tls_certificate_path()メソッドを提供するようになりました。
詳細については、TLS Link Encryption for NDB Clusterおよびndb_sign_keys - Create, Sign, and Manage TLS Keys and Certificates for NDB Clusterを参照してください。（WL #15135、WL #15154、WL #15166、WL #15521）

バグ修正

NDBレプリケーション: 内部スレッドのメモリ使用量の自己チェックが厳密すぎるため、不必要なファイルローテーションが発生し、メモリ使用量が増加する可能性がありました。（バグ #35657932）
NDBレプリケーション: ソースクラスターでCREATE USERを実行すると、レプリカクラスターに接続されているSQLノードが終了しました。（バグ #34551954）
参考: バグ #112775、バグ #33172887、バグ #33542052、バグ #35928350も参照してください。
NDBレプリケーション: レプリケーションフィルターを有効にしてGRANT NDB_STORED_USERステートメントをレプリケートすると、SQLノードが終了しました。これは、レプリケーションフィルターにより、変更のみをレプリケートする必要があると想定され、全ての非更新クエリでエラーが返されたために発生しました。
（バグ #112775、バグ #35928350）
参考: バグ #34551954、バグ #33172887、バグ #33542052も参照してください。
NDBレプリケーション: レプリカクラスター内のSQLノードがread_only=ONになっているNDBレプリケーションセットアップでは、ソースクラスターでのDROP DATABASEステートメントにより、レプリカサーバー上のSQLスレッドがWaiting for schema metadata lockでハングアップしました。
NDB Cluster API: NDB APIのイベントバッファオーバーフローにより、DROP TABLEの待機中にタイムアウトが発生する可能性がありました。（バグ #35655162）
参考: バグ #35662083も参照してください。
ndbinfo情報データベース: ndbinfoの実装では、データノードがいつでも特定のテーブルに対して常に同じテーブルIDを使用することが前提となっています。これには、ローリングアップグレード中に不整合が生じる可能性があるため、特定のテーブルIDをNDB Clusterの異なるバージョンの異なるテーブル間で移動しないことが必要です。ndbinfoテーブルが最新リリースにのみ追加され、以前のリリースシリーズにバックポートされない場合、この制約は非常に簡単に維持されますが、バックポートの場合には問題が発生する可能性がありました。
新しいリリースシリーズで追加された特定のndbinfoテーブルが後で古いテーブルにバックポートされた場合、そのテーブルは新しいリリースと同じIDを使用するようになりました。（バグ #28533342）
ノード障害が検出されると、トランザクションコーディネーター（TC）インスタンスは自身のトランザクションをチェックして、確実に完了するための処理が必要かどうかを判断します。これは、各トランザクションに障害が発生したノードが含まれているかどうかをチェックし、含まれている場合は即時にタイムアウト処理するようにマークすることで実装されます。これにより、シリアルコミットプロトコルを使用して、トランザクションがコミットを開始したかどうかに応じて、トランザクションがロールフォワード（コミット）またはロールバック（中止）されます。TCがコミット許可の取得（CS_PREPARE_TO_COMMIT）、コミット要求の送信（CS_COMMITTING）、または完了要求の送信（CS_COMPLETING）のプロセス中に、タイムアウト処理はシリアルコミットプロトコルを開始する前にトランザクションが安定した状態になるまで待機しました。
バグ #22602898が修正される前は、CS_COMPLETINGまたはCS_COMMITTING中の全てのタイムアウトによりシリアルコミット完了プロトコルに切り替わるため、前述の3つの状態のいずれかで処理をスキップしても、ノード障害のプロンプト処理は停止されませんでした。この修正により、コミット完了タイムアウトに対するシリアルコミット完了プロトコルの一括使用が削除されたため、これらの状態の処理がスキップされた場合、ノード障害の処理アクションが実行されず、その結果、そのようなトランザクションはコミットフェーズまたは完了フェーズでハングし、チェックポイントがブロックされることが後で判明しました。
バグ #22602898の修正では、それが誤ってトリガーされるのを避けるためにこの安定状態の処理が削除されましたが、この変更により、ノード障害の処理で一時的な状態のトランザクションが見つかった場合、それが必要とされる時にトリガーされることも停止されました。現在の最新の障害番号とは異なる障害番号を持つトランザクションでタイムアウトが発生した場合にノード障害処理を実行するようにCS_COMMIT_SENTおよびCS_COMPLETE_SENTの安定状態処理を変更し、障害が発生したノードに関係する全てのトランザクションが実際に最終的に処理されるようにすることで、この問題を解決します。（バグ #36028828）
参考: バグ #22602898も参照してください。
QMGRブロックのGSN_ISOLATE_ORD信号処理は、最大144個のデータノードをサポートするために必要なより大きなノードビットマップサイズを処理するために、以前の問題の修正によって変更されました。その後、ISOLATE_ORDの処理時に元の送信者が既にシャットダウンされている可能性があることが判明しました。その場合、ノードのバージョンが0にリセットされ、インラインビットマップパスが使用され、その結果誤った処理が行われる可能性がありました。
シグナルハンドラーは、受信信号が分離するノードを表すために長いセクションを使用しているかどうかを判断するために確認し、それに応じて動作するようになりました。（バグ #36002814）
参考: バグ #30529132も参照してください。
mysql.ndb_apply_statusがバイナリロギングスレッドによって管理されるユーティリティテーブルであり、変更をチェックする必要がないため、Metadata: Failed to submit table 'mysql.ndb_apply_status' for synchronizationのようなメッセージがエラーログに毎分送信され、ログが不必要にいっぱいになってしまいました。（バグ #35925503）
DBSPJ関数 releaseGlobal()は、m_free_page_listに維持されている余分なページを解放する役割を果たします。この関数はリストを反復処理し、オブジェクトを解放し、16回反復した後にリアルタイムで中断します。リアルタイムブレイクと並行して、DBSPJはCONTINUEB信号を遅延して自身に送信することでreleaseGlobal()の新しい呼び出しを生成しました。これにより、送信される信号の数を制御できないため、長時間キューのオーバーフローが発生する可能性がありました。
リアルタイムブレイクが行われた時に、余分に遅延したCONTINUEB信号を送信しないようにすることで、この問題を修正しました。（バグ #35919302）
データノードの再起動中のAPIノードの障害処理により、そのサブスクリプションが残されました。（バグ #35899768）
未使用のファイル storage/ndb/tools/restore/consumer_restorem.cppを削除しました。（バグ #35894084）
ndb_print_backup_fileによって出力される不要な出力を削除しました。（バグ #35869988）
トランスポーターコードで再利用されたファイル記述子に対する誤った読み取りまたは書き込みの可能性を削除しました。（バグ #35860854）
read_socket()、readln_socket()、NdbSocket::read()、または NdbSocket::readln()などの時限読み取り関数が無効なソケットを使用して呼び出された場合、回復不可能な障害を示す予想される-1ではなく、タイムアウトを示す0が返されました。これは、poll()関数を使用する時に特に顕著でした。この問題の結果、無効なソケットが適切に処理されず、単にそのソケットに対してイベントがまったく発生しませんでした。（バグ #35860646）
storage/ndb/src/common/util/socket_io.cppのreadln_socket()関数が、引数として渡されたバッファから1文字多すぎる文字を読み取る可能性がありました。（バグ #35857936）
consolidate()がどれだけの完全なバッファがそれに収まるかを計算するため、ssl_write()は再試行時に予想よりも小さな送信バッファを受信する可能性がありました。統合の前にこれらのバッファを事前にパックするようにしました。（バグ #35846435）
オンラインテーブルの再編成中に、新しいフラグメントに移動された行には、後のコピーフェーズで削除できるようにタグが付けられます。このタグ付けには、タプルヘッダー内のREORG_MOVEDビットの設定が含まれます。これはタプルヘッダーのチェックサムに影響するため、変更後に再計算される必要があります。場合によっては、これはREORG_MOVEDが設定される前に計算されるため、後で同じタプルにアクセスするとタプルヘッダーのチェックサムの不一致で失敗する可能性があります。この問題は、BLOB値のテーブル挿入と同時にALTER TABLE REORGANIZE PARTITIONを実行した時に発生し、MySQL 8.0.23での設定可能なクエリスレッドの導入の副作用であると考えられます。
このようなケースでは、チェックサムが計算される前にREORG_MOVEDが設定されていることを確認するようにしました。（バグ #35783683）
ノード接続の失敗後、再接続を開始する前にトランスポーターレジストリのエラー状態がクリアされませんでした。これは、最初に接続の切断を引き起こしたエラーがまだ設定されている可能性があることを意味します。これは再接続の失敗として解釈されました。（バグ #35774109）
ENOMEM（メモリの終わり）エラーが発生すると、TCPトランスポーターは後続のバッファの送信を試行し続けたため、データの破損やチェックサムのエラーが発生する可能性がありました。
TCPトランスポーターからENOMEM処理を削除し、代わりに十分なメモリが利用可能になるまで待機することで、この問題を修正しました。（バグ #35700332）
バイナリログインジェクターのセットアップは、同時DDLでデッドロックする場合がありました。（バグ #35673915）
管理サーバーが利用できない時にデータノードの切断が遅くなると、ローリング再起動プロセスが妨げられる場合がありました。これは、クラスターがNDB Operatorによってホストされており、古いmgmdポッドが再起動されたデータノードポッドのIPアドレスの変更を認識しなかった場合に特に顕著になりました。これは、異なる管理ノード上のSHOW STATUSの出力の不一致として確認できました。
データノードに接続する時にキャッシュされたアドレスを必ずクリアして、データノードの新しいアドレス（存在する場合）が代わりに使用されるようにすることで、この問題を修正しました。（バグ #35667611）
復元可能な最も古いグローバルチェックポイントIDの最大許容値は、MAX_INT32（4294967295）です。IDがこの値より大きい場合、データノードがシャットダウンされ、--initialで開始されたクラスター上でバックアップと復元が必要になります。
現在は、通常の使用状況でこの制限に達する約90日前に、適切な警告が発行され、必要な是正措置を計画する時間が与えられます。（バグ #35641420）
参考: バグ #35749589も参照してください。
サイズがbinlog_cache_sizeを超えたトランザクションにより、重複した警告が発生しました。（バグ #35441583）
log_replica_updatesがOFFに設定されている場合でも、一部のテーブルのテーブルマップエントリがバイナリログに書き込まれました。（バグ #35199996）
NDBソースコードは、clang-formatで使用されるルールに従ってフォーマットされ、この点で残りのMySQLソースと一致するようになります。（バグ #33517923）
ノードの再起動中にサブスクリプションレポートがSUMAによって送信されるのが早過ぎたため、クラスターSQLノード間でスキーマの不整合が発生する可能性がありました。さらに、ndbinfo restart_infoテーブルの問題により、どのノードグループにも属していないノードの再起動フェーズが常に正しく報告されないことがありました。（バグ #30930132）
オンラインテーブル再編成では、既存のテーブルフラグメントの行が新しいテーブルフラグメントに挿入されます。次に、挿入された行をコミットした後、元の行を削除します。挿入によりSUMAトリガーが起動され、バイナリログが発生し、次の問題が発生することが判明しました：
- DDLは通常、行レベルの影響ではなく、ログに記録される場合でも、1つ以上のステートメントとしてログに記録されるため、動作に一貫性がありません。
- 書き込みのみが記録され、削除は記録されなかったため、これは不正確でした。
- BLOBを含むテーブルは、有効なバイナリログイベントを形成するために必要な関連する行変更を受け取らなかったため、安全ではありませんでした。
- CPUやその他のリソースを不必要に使用していました。
BLOB列のないテーブルの場合、これは主にパフォーマンスの問題でした。BLOB列を持つテーブルの場合、この動作により、バイナリロギングを実行するmysqldプロセスが計画外にシャットダウンされ、ダウンストリームでデータが破損する可能性もありました。（バグ #19912988）
参考: バグ #16028096、バグ #34843617も参照してください。
NDB APIイベントは、ユーザーコードによる生成と消費のレートに合わせてバッファリングされます。レートが長時間一致しない場合に無制限のメモリ使用を避けるために設定された最大サイズに達すると、バッファ使用量が下限しきい値を下回るまでイベントバッファリングが停止しました。これは、NODE_FAILREPイベントを処理する時に最新のエポックのコンテナが見つからないこととして現れました。この問題を解決するためには、TE_OUT_OF_MEMORYイベントをバッファに追加して、欠落しているイベントがある可能性があることをコンシューマーに通知します。

全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL NDB Cluster 8.3.0 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql-cluster/8.3/en/news-8-3-0.html

MySQL Editions

MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。