コンパイル関連
- NDB Clusterは、Ubuntu 23.10で正しくコンパイルされませんでした。（バグ #35847193）
- s390xプラットフォーム用のNDB Clusterを構築できるようになりました。
（バグ #110807、バグ #35330936）
バグ修正
- NDBレプリケーション: 内部スレッドのメモリ使用量の自己チェックが厳密すぎるため、不必要なファイルローテーションが発生し、メモリ使用量が増加する可能性がありました。（バグ #35657932）
- NDBレプリケーション: ソースクラスターでCREATE USERを実行すると、レプリカクラスターに接続されているSQLノードが終了しました。（バグ #34551954）
参考: バグ #112775、バグ #33172887、バグ #33542052、バグ #35928350も参照してください。 - NDBレプリケーション: NDB テーブルのレプリケーションは、次の状況で停止しました。
- テーブルに明示的なプライマリキーがなかった
- テーブルにBIT列が含まれていた
- 更新または削除される行を見つけるためにハッシュスキャンが使用された
この問題を解決するために、テーブルのハッシュ キーがソースとレプリカで一致することを確認するようになりました。（バグ #34199339）
- 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） - NDBクライアントプログラム: --bind-address=localhostを指定してndb_mgmdを起動しようとすると、Illegal bind addressというエラーが発生して失敗しました。このエラーは、バインドアドレスを解析してホスト部分とポート部分に分割しようとした時にMGM APIから返されました。このような場合、localhostが有効なアドレスとして受け入れられるようになりました。（バグ #36005903）
- ノード障害が検出されると、トランザクションコーディネーター（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も参照してください。 - start_clients_thread()とupdate_connections()の両方がDISCONNECTING状態の同じトランスポータを認識しているために、start_clients_thread()とupdate_connections()の間で発生する可能性のある競合状態を削除しました。現在は、トランスポータが切断されたことを示す設定を行う前に、切断が実際に完了していることを確認します。これにより、update_connections()は、完全にシャットダウンされる前にNdbSocketを閉じることができなくなります。（バグ #36009860）
- トランスポータが過負荷になると、送信スレッドは期待どおりにCPUに譲らず、ハードコードされた200マイクロ秒のタイムアウトに達するまでトランスポータを繰り返し再試行します。（バグ #36004838）
- QMGRブロックのGSN_ISOLATE_ORD信号処理は、最大144個のデータノードをサポートするために必要なより大きなノードビットマップサイズを処理するために、以前の問題の修正によって変更されました。その後、ISOLATE_ORDの処理時に元の送信者が既にシャットダウンされている可能性があることが判明しました。その場合、ノードのバージョンが0にリセットされ、インラインビットマップパスが使用され、その結果誤った処理が行われる可能性がありました。
シグナルハンドラーは、受信信号が分離するノードを表すために長いセクションを使用しているかどうかを判断するために確認し、それに応じて動作するようになりました。（バグ #36002814）
参考: バグ #30529132も参照してください。 - スキーマ配布から切断されたMySQLサーバーは、イベント内でテーブル列が見つからなかったために、イベント操作を設定できませんでした。これは、ndb_drop_tableを使用するか、MySQLサーバーを使用して作成されたNDBからテーブルを直接削除する別の手段を使用することによって発生する可能性がありました。
このような場合に、ディクショナリキャッシュからNDBテーブル定義を適切に無効にすることで、この問題を修正します。（バグ #35948153） - 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）
- ユーティリティテーブルのセットアップ中、スキーマイベントハンドラーは、グローバルスキーマロック（GSL）が使用可能になるのを待ってハングすることがありました。これは、物理テーブルがクラスターから削除された場合、または、他の理由で接続が失われた場合に発生する可能性がありました。現在、このような場合にGSLを取得しようとする時にはtryロックを使用するようになりました。これにより、グローバルスキーマロックが利用できない場合には、後で別のセットアップ チェックが試行されます。（バグ #32550019、バグ #35949017）
- ノードの再起動中にサブスクリプションレポートが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.0.36 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-36.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。