バグ修正
- NDBレプリケーション: 文字タイプのプライマリキーの更新は、NDBバイナリログインジェクターに送信されるBEFOREおよびAFTERトリガーの値で正しく示されませんでした。この問題は以前に部分的に修正されましたが、次にリストされる値を持つバイナリロギングオプションを使用してmysqldを実行すると依然として問題が発生することがその後判明しました:
- --ndb-log-update-minimal=ON
- --ndb-log-update-as-write=OFF
minimalバイナリログ形式では、更新された行を反映するAFTER値から全てのプライマリキー列が除外されました。この根拠は、更新トリガーを受信した時にプライマリキーが一定のままであるという誤った仮定です。これは、プライマリキーが文字データタイプを使用する場合に、使用される照合順序の比較規則によって等しいものとして扱われる値に文字の列が更新されると、更新トリガーが受信されるという事実を考慮していませんでした。
このような変更を複製できるようにするためには、変更をAFTER値に含める必要があります。この修正により、それは確実に行われます。 (バグ #34540016)
参考: バグ #27522732、バグ #34312769、バグ #34388068。 - NDB Cluster API: ヘッダーファイル ndb_version.hおよびmgmapi.hは、Cのみを必要とするはずであるにもかかわらず、コンパイルにC++を必要としました。 (バグ #35709497)
- NDB Cluster API: Ndb::pollEvents2()は、クラスターの障害を示す NDB_FAILURE_GCI (~(Uint64)0)を設定しませんでした。 (バグ #35671818)
参考: バグ #31926584。この問題は、バグ #18753887のリグレッションです。 - NDBクライアントプログラム: ndb_select_allがテーブルから全てのデータを読み取ることができなかった場合、常に再読み取りを試行していました。これにより、以下の2つの問題が発生する可能性がありました:
- 空ではない部分的な結果を返すと、最終的には重複行の誤ったレポートが生成されました。
- テーブルヘッダーは再試行の度に出力されました。
現在は、ndb_select_allが全てのテーブルデータの読み取りに失敗した場合、その動作は以下のようになります:
- 結果が空でない場合、ndb_select_allはエラーで停止します（そして、テーブルのスキャンは再試行されません）。
- 結果が空の場合、ndb_select_allは古いヘッダーを再利用してスキャンを再試行します。
(バグ #35510814)
- NDB ClusterはClang 15を使用してコンパイルされませんでした。(バグ #35763112)
- TransporterRegistry（TR）インスタンスが管理サーバーに接続する時、最初にMGM APIを使用し、それから、その後の通信のために接続をTransporter接続に変換します。最初の接続のタイムアウトが長すぎる（60秒）ため、クラスタに2つの管理サーバーがあり、そのうちの1つが使用不能の場合、クライアントは、利用可能な管理サーバーに接続できるようになる前、この使用不能な管理サーバーがタイムアウトになるまで待機する必要がありました。
この問題は、MGM API接続タイムアウトを5000ミリ秒に設定することによって修正されます。これは、TRが動的ポートの取得と設定に使用するタイムアウトと等しいです。 (バグ #35714466) - 競合解決例外テーブルで使用される競合の原因の値の位置がずれており、ROW_ALREADY_EXISTSとROW_DOES_NOT_EXISTの順序が逆になっていました。 (バグ #35708719)
- TLSがTCP トランスポーター上で使用される場合、基礎となるSSL_write()がSSL_ERROR_WANT_READまたはSSL_ERROR_WANT_WRITEを返した場合、 ssl_writev()メソッドはTLS_BUSY_TRY_AGAINを返すことがあります。これは、後で書き込みを再試行する必要があることを上位層に示すために使用されます。
TCP_Transporter::doSend()は、バッファされたデータの複数のブロックが一連のwritev()呼び出しを使用して書き込まれるループで書き込む可能性があるため、SSL_ERROR_WANT_WRITEが発生する前にバッファされたデータの一部が正常に書き込まれている可能性があります。このような場合、TLS_BUSY_TRY_AGAINの処理は、送信された内容をバッファリング層に通知するために最初にiovec_data_sent(sum_sent)を呼び出すことなく、単にループから戻るだけでした。
この結果、後で、既に送信されたチャンクの再送信が試行され、重複したデータと不正な長さの引数の両方を指定してwritev()が呼び出されました。その結果、チェックサムエラーとSSL writev()が失敗し、不正な長さのエラーがログに報告されました。
この問題は、単に送信ループから戻るのではなく、ループから抜け出すことによって修正され、実行はそのようなステータス更新が行われるコード内のポイントまでフォールスルーされます。 (バグ #35693207) - ブロックが以前にDUMP 9992を使用して設定されていなかったデータノードから信号ブロックを解放しようとしてDUMP 9993が使用されると、データノードが予期せずシャットダウンしました。 (バグ #35619947)
- 不正なリクエストに対するNDBFSデバッグ出力が改善されました。 (バグ #35500304)
参考: この問題は、バグ #28922609のリグレッションです。 - 他のイベントによってNDBFSのリクエストがログにダンプされると、リクエストタイプの名前の一部がUnknownアクションとして出力されました。 (バグ #35499931)
- ndb_restoreは、バックアップ中に変更された等しいものとして比較するプライマリキー値を更新しませんでした。 (バグ #35420131)
- NOWAITを使用したバックアップは、データノードの再起動後に開始されませんでした。 (バグ #35389533)
- データノードプロセスは、ソフトウェアエラー以外の状況によるプログラム終了時にスタックトレースを出力し、場合によっては混乱が生じる可能性がありました。 (バグ #34836463)
参考: バグ #34629622。 - データノードプロセスがUnixシグナル（kill -6付きなど）を受信すると、シグナルハンドラー関数はスタックトレースを表示し、その後ErrorReporterを呼び出し、これもスタックトレースを表示しました。
現在はこのような場合、ErrorReporterはこの状況をチェックし、シグナルハンドラーから呼び出された時に独自のスタックトレースを出力しません。 (バグ #34629622) - 分散グローバルチェックポイント（GCP）プロトコルの進行が停止した場合、これはGCPモニターによって検出され、オプションで、TimeBetweenEpochsTimeoutおよび TimeBetweenGlobalCheckpointsTimeoutデータノードパラメータによって決定される処理を使用して処理されます。
LCPプロトコルはほとんどノードローカルですが、ローカルチェックポイント（LCP）の終わりでGCPプロトコルの進行状況に依存します。これは、GCPプロトコルが停止すると、LCPもこの状態で停止する可能性があることを意味します。LCPウォッチドッグはLCPがこの最終状態で停止していることを検出した場合、GCPモニターはディストリビューションを認識しているため、この状況の処理をGCPモニターに委ねる必要があります。
GCPモニター制限が設定されていない場合（TimeBetweenEpochsTimeoutが0に等しい）、GCPストールの処理はGCPモニターによって実行されません。この場合、LCPウォッチドッグは依然としてアクションを実行しており、最終的にはクラスター障害につながる可能性がありました。この修正により、この不正な動作が修正され、LCPウォッチドッグはそのようなアクションを実行しなくなります。 (バグ #29885899) - 以前は、トランザクションのコミットおよび完了中にタイムアウトが検出されると、トランザクションコーディネーター（TC）がシリアルコミット完了実行プロトコルに切り替わりました。これにより、大規模なトランザクションのコミット完了処理が遅くなり、GCP_COMMITの遅延とエポックサイズに影響を及ぼしました。このような場合に切り替える代わりに、TCは並行コミットの完了を待ち続け、状態とノードが関係するトランザクションの概要を定期的にログに記録します。 (バグ #22602898)
参考: バグ #35260944。 - ALTER TABLEがテーブルに列を追加すると、行のバッファー領域を割り当てるためにローカルチェックポイントによって使用されるmaxRecordSizeが変更される場合があります。これは、GET_TABINFOCONFシグナルで設定され、後でBACKUP_FRAGMENT_REQで再度使用されます。これらの2つのシグナルの間のギャップ中に、ALTER TABLEが列の数を変更した場合、使用されるmaxRecordSizeの値は、古い可能性があるため不正確になる可能性があり、さらなる問題が発生する可能性があります。
現在は、行バッファの割り当てを試みる前に、BACKUP_FRAGMENT_REQシグナルの受信時に常に（DBTUPからの）maxRecordSizeを更新します。 (バグ #105895、バグ #33680100)
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL NDB Cluster 8.0.35 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-35.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。