バグ修正
- InnoDB: エンジンステータスログの最後に検出されたデッドロックセクションには、スレッドとクエリの情報を合わせた1024文字しか表示されていませんでした。出力されるクエリ文字列の制限を削除することによって修正しました。 (バグ #80927、バグ #23036096)
- 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::pollEvents2()は、クラスターの障害を示す NDB_FAILURE_GCI (~(Uint64)0)を設定しませんでした。 (バグ #35671818)
参考: バグ #31926584。この問題は、バグ #18753887のリグレッションです。 - NDBクライアントプログラム: ndb_select_allがテーブルから全てのデータを読み取ることができなかった場合、常に再読み取りを試行していました。これにより、以下の2つの問題が発生する可能性がありました:
- 空ではない部分的な結果を返すと、最終的には重複行の誤ったレポートが生成されました。
- テーブルヘッダーは再試行の度に出力されました。
現在は、ndb_select_allが全てのテーブルデータの読み取りに失敗した場合、その動作は以下のようになります:
- 結果が空でない場合、ndb_select_allはエラーで停止します（そして、テーブルのスキャンは再試行されません）。
- 結果が空の場合、ndb_select_allは古いヘッダーを再利用してスキャンを再試行します。
(バグ #35510814)
- ノード接続の失敗後、再接続を開始する前にトランスポータレジストリのエラー状態がクリアされませんでした。これは、もともとの接続の切断を引き起こしたエラーがまだ設定されている可能性があることを意味します。これは再接続の失敗として解釈されました。 (バグ #35774109)
- TransporterRegistry（TR）インスタンスが管理サーバーに接続する時、最初にMGM APIを使用し、それから、その後の通信のために接続をTransporter接続に変換します。最初の接続のタイムアウトが長すぎる（60秒）ため、クラスタに2つの管理サーバーがあり、そのうちの1つが使用不能の場合、クライアントは、利用可能な管理サーバーに接続できるようになる前、この使用不能な管理サーバーがタイムアウトになるまで待機する必要がありました。
この問題は、MGM API接続タイムアウトを5000ミリ秒に設定することによって修正されます。これは、TRが動的ポートの取得と設定に使用するタイムアウトと等しいです。 (バグ #35714466) - 競合解決例外テーブルで使用される競合の原因の値の位置がずれており、ROW_ALREADY_EXISTSとROW_DOES_NOT_EXISTの順序が逆になっていました。 (バグ #35708719)
- 不正なリクエストに対するNDBFSデバッグ出力が改善されました。 (バグ #35500304)
参考: この問題は、バグ #28922609のリグレッションです。 - 他のイベントによってNDBFSのリクエストがログにダンプされると、リクエストタイプの名前の一部がUnknownアクションとして出力されました。 (バグ #35499931)
- ndb_restoreは、バックアップ中に変更された等しいものとして比較するプライマリキー値を更新しませんでした。 (バグ #35420131)
- 分散グローバルチェックポイント（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。
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL NDB Cluster 7.6.28（5.7.44-ndb-7.6.28）リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/news-7-6-28.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。