コンパイル関連
- Microsoft Windows: NDB Clusterは、Visual Studio 2022を使用して正しくコンパイルされませんでした。
- NDB Clusterは、Ubuntu 23.10で正しくコンパイルされませんでした。（バグ #35847193）
プラガブル認証
- このリリース以降、PAM認証プラグインのデバッグに使用されるAUTHENTICATION_PAM_LOG環境変数の動作が次のように変更されます:
- AUTHENTICATION_PAM_LOGを任意の値に設定すると（次の項目で説明する場合を除き）、診断メッセージにパスワードが含まれなくなります。
- 診断メッセージにパスワードを含めるためには、AUTHENTICATION_PAM_LOG=PAM_LOG_WITH_SECRET_INFOを設定します。
詳細については、PAM Authentication Debuggingを参照してください。（バグ #74313、バグ #20042010）
バグ修正
- ノード障害が検出されると、トランザクションコーディネーター（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も参照してください。 - storage/ndb/src/common/util/socket_io.cppのreadln_socket()関数が、引数として渡されたバッファから1文字多すぎる文字を読み取る可能性がありました。（バグ #35857936）
- 限られたケースではありますが、データをMD5()暗号化関数に渡すとサーバーが停止する可能性がありました。（バグ #35764496）
- 管理サーバーが利用できない時にデータノードの切断が遅くなると、ローリング再起動プロセスが妨げられる場合がありました。これは、クラスターがNDB Operatorによってホストされており、古いmgmdポッドが再起動されたデータノードポッドのIPアドレスの変更を認識しなかった場合に特に顕著になりました。これは、異なる管理ノード上のSHOW STATUSの出力の不一致として確認できました。
データノードに接続する時にキャッシュされたアドレスを必ずクリアして、データノードの新しいアドレス（存在する場合）が代わりに使用されるようにすることで、この問題を修正しました。（バグ #35667611） - 復元可能な最も古いグローバルチェックポイントIDの最大許容値は、MAX_INT32（4294967295）です。IDがこの値より大きい場合、データノードがシャットダウンされ、--initialで開始されたクラスター上でバックアップと復元が必要になります。
現在は、通常の使用状況でこの制限に達する約90日前に、適切な警告が発行され、必要な是正措置を計画する時間が与えられます。（バグ #35641420）
参考: バグ #35749589も参照してください。 - ノードの再起動中にサブスクリプションレポートがSUMAによって送信されるのが早過ぎたため、クラスターSQLノード間でスキーマの不整合が発生する可能性がありました。さらに、ndbinfo restart_infoテーブルの問題により、どのノードグループにも属していないノードの再起動フェーズが常に正しく報告されないことがありました。（バグ #30930132）
- オンラインテーブル再編成では、既存のテーブルフラグメントの行が新しいテーブルフラグメントに挿入されます。次に、挿入された行をコミットした後、元の行を削除します。挿入によりSUMAトリガーが起動され、バイナリログが発生し、次の問題が発生することが判明しました：
- DDLは通常、行レベルの影響ではなく、ログに記録される場合でも、1つ以上のステートメントとしてログに記録されるため、動作に一貫性がありません。
- 書き込みのみが記録され、削除は記録されなかったため、これは不正確でした。
- BLOBを含むテーブルは、有効なバイナリログイベントを形成するために必要な関連する行変更を受け取らなかったため、安全ではありませんでした。
- CPUやその他のリソースを不必要に使用していました。
BLOB列のないテーブルの場合、これは主にパフォーマンスの問題でした。BLOB列を持つテーブルの場合、この動作により、バイナリロギングを実行するmysqldプロセスが計画外にシャットダウンされ、ダウンストリームでデータが破損する可能性もありました。（バグ #19912988）
参考: バグ #16028096、バグ #34843617も参照してください。
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL NDB Cluster 7.6.29 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/news-7-6-29.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。