MySQL NDB Cluster 7.6.12 GA版（リリース日：2019年10月15日）

主な変更点

■ 追加・変更された機能

● ndb_restoreは、バックアップの.ctlファイルからテーブル記述子をロードできない時に、特定のNDBエラー番号とメッセージを報告するようになりました。これは、より最近のバージョンのNDB Clusterソフトウェアから取得したバックアップを以前のバージョンを実行しているクラスターに復元しようとした時に発生する可能性があります。例えば、バックアップがその復元に使用されているndb_restoreのバージョンには不明な文字セットを使用するテーブルを含む場合。 (Bug #30184265)

● ndb_mgmクライアントのDUMP 1000からの出力が拡張され、データページの合計使用量に関する情報が提供されるようになりました。 (Bug #29841454)

　参照：Bug #29929996

■ バグ修正

● NDBディスクデータ：データノードがディスク上で列を持つNDBテーブルを作成しデータを投入した後に失敗した時、ただしローカルチェックポイントの実行前に、テーブルスペースから行データを失う可能性がありました。 (Bug #29506869)

● MySQL NDB ClusterJ：ClusterJがマルチモジュールWebアプリケーションの独立したモジュールとしてデプロイされた場合、アプリケーションがドメインオブジェクトの新しいインスタンスを作成しようとした時、例外java.lang.IllegalArgumentException: non-public interface is not defined by the given loaderが投げられました。これは、ClusterJが常にドメインオブジェクトをインスタンス化できるプロキシクラスを作成しようとし、プロキシクラスはドメインインターフェイスと保護されたDomainTypeHandlerImpl::Finalizableインターフェイスの実装であるからです。これらの2つのインターフェースのクラスローダーは、Webサーバーで稼働している別々のモジュールに属していたため、状況が異なりました。そのため、ClusterJがドメインオブジェクトインターフェイスのクラスローダーを使用してプロキシクラスを作成しようとすると、上記の例外が投げられました。この修正により、Finalizationインターフェースがパブリックになり、Webアプリケーションのクラスローダーがドメインインターフェースのクラスローダーとは異なるモジュールに属している場合でもアクセスできるようになりました。 (Bug #29895213)

● MySQL NDB ClusterJ：ClusterJは、NDB Clusterに再接続した後、セグメンテーション違反で失敗することがありました。これは、ClusterJが古い接続から古いデータベースメタデータオブジェクトを再利用したためです。この修正により、それらのオブジェクトはクラスタへの再接続の前に破棄されます。 (Bug #29891983)

● データノードが起動されるとすぐに、その設定されたDataMemoryの95%が通常のデータのために使用可能になり、5%は重大な状況で使用するために取っておかれます。ノードの起動プロセス中、その設定されたDataMemoryのすべてがデータに使用できます。これは、ノードが停止された時よりも同じデータのためにより多くのページを使用するいくつかの動的メモリ構造が原因でデータメモリが不足したためにノードデータの復元が失敗するリスクを最小限に抑えるためです。例えば、テーブルへの挿入の順序は履歴の順序と異なるので、再起動中のハッシュテーブルの生成は以前とは異なります。

　このバグレポートで取り上げられた問題は、使用済みのデータメモリとスペアのデータメモリがDataMemoryに設定された値を超えていないことのチェックが、スペアメモリが取っておかれた時点で失敗した時に発生しました。これは、スペアページを取っておく場合に、データノードの状態が起動中から起動済みに移行した時に発生しました。スペアのメモリに使用するために取っておいたページの数を計算し、次にこれに使用する共有ページ（つまり、共有グローバルメモリからのページ）の数を計算すると、すでに割り当てられている取っておいたページの数は考慮されていませんでした。 (Bug #30205182)

　参照：Bug #29616383。

● グローバルスキーマロック（GSL）を実行する場合、NDBはテーブルオブジェクト参照を取得しようとする時に、連続するリタイアのために単一のNdb_table_guardオブジェクトを使用しました。基礎となるオブジェクトポインターがその後にキャッシュされた参照から返される以前に取得されたポインターで初期化時に一度だけ決定されるとNdb_table_guardが仮定するために、これは最初の試行で失敗すると成功する可能性はありませんでした。

　これにより、GSLを取得するために無限の待機が発生し、binlogインジェクタースレッドがハングして、mysqldがすべてのNDBテーブルを読み取り専用と見なしました。この問題を回避するために、NDBはそのような再試行ごとにNdb_table_guardの新しいインスタンスを使用するようになりました。 (Bug #30120858)

　参照：この問題は、Bug #30086352のリグレッションです。

● 起動時に、最初に完了したローカルチェックポイントと開始フェーズ50との間にデータノードのローカルsysfileが更新されませんでした。 (Bug #30086352)

● BACKUPブロックでは、c_backupsの最初のレコードがローカルチェックポイントレコードであると仮定されましたが、常にそうであるとは限りません。現在は、NDBはc_backupsのレコードをループスルーして、代わりに（正しい）LCPレコードを見つけます。 (Bug #30080194)

● マスターのノードテイクオーバー中、残りのデータノードがLCP_TAB_SAVEDとして状態を報告しているにもかかわらず、LCP_STATUS_IDLE状態で終了することが可能でした。これは、アイドルの時に予期されないため、LCP_COMPLETE_REP信号の受信を処理しようとした時にノードのエラーにつながりました。現在、このような場合、このノードが適切な状態（LCP_TAB_SAVED）で確実に終了する方法で、ローカルチェックポイント処理が行われます。 (Bug #30032863)

● NDB 7.4から作成されたバックアップからNDB 7.6を実行しているクラスターにパーティションを変更するためMAX_ROWSが使用されたテーブル復元が正しく機能しませんでした。これは、PartitionBalanceを処理するアップグレードコードがNDBディクショナリに有効なテーブル仕様を確実に提供するようにすることで解決されます。 (Bug #29955656)

● データノードの半分がNDB 7.6を実行し、残りがNDB 8.0を実行していたNDBクラスターのアップグレード中に、NDB 7.6を実行していたノードをシャットダウンしようとすると、エラー CHECK FAILEDNODEPTR.P->DBLQHFAIで1つのノードに障害が発生しました。 (Bug #29912988, Bug #30141203)

● ローカルチェックポイント（LCP）を実行する時、テーブルのスキーマのバージョンが断続的に0として読み取られたため、NDB LCP処理はテーブルが削除されているかのようにテーブルを処理しました。これは、テーブルがTABLE_READ_ONLY状態の時にndb_restoreによるオフラインでのインデックスの再構築に影響を与える可能性がありました。現在、スキーマのバージョンを読み取る関数（getCreateSchemaVersion()）は、テーブルが読み取り専用である間はそれを変更しません。 (Bug #29910397)

● NDBインデックス統計は、順序付けされたインデックスの1つのフラグメントのトポロジに基づいて計算されます。特定のインデックスで選択されたフラグメントは、インデックスが最初に作成された時と、ノードまたはシステムの再起動がインデックスをローカルに再作成した時の両方で、インデックス作成時に決定されます。この計算は、インデックス内のフラグメントの数に一部基づいており、テーブルが再編成されると変更される可能性があります。これは、次回ノードが再起動される時に、このノードが別のフラグメントを選択する可能性があるため、インデックス統計の生成に1つまたは2つのフラグメントが使用されるか、フラグメントが全く使用されず、結果としてANALYZE TABLEからエラーが発生することを意味します。

　この問題は、選択したフラグメントをすぐに再計算するようにオンラインテーブル再編成を修正することで解決され、その後の再起動の前後にすべてのノードが整列されます。 (Bug #29534647)

● データノードが起動したがまだpresidentに選出されていない時の再起動中に、管理サーバーがnode ID already in useエラーを受信したため、過剰な再試行とロギングが発生しました。これは、このケースのために新しいエラー1705 Not ready for connection allocation yetを導入することで解決されています。

　データノードがノード障害処理をまだ完了していない時の再起動中に、誤ったFailed to allocate nodeIDエラーが返されました。これは、不完全なノード起動を検出し、代わりにエラー1703 Node failure handling not completedを返すチェックを追加することで解決されています。

　この修正の一部として、nodeIDエラーを割り当てる準備ができていない場合の再試行の頻度が減り、テスト目的で遅い再起動をシミュレートするためにエラー挿入が追加され、関連するノードID割り当てエラーがマイナーで一時的なものであることを示すためにログメッセージが書き直されました。 (Bug #27484514)

● トランザクションコーディネーターを選択するプロセスは、“live”データノードをチェックしましたが、実際に利用可能なデータノードは必ずしもチェックしませんでした。 (Bug #27160203)

MySQL NDB Cluster 7.6.12リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/news-7-6-12.html

---