MySQL NDB Cluster 8.0.19 GA版（リリース日：2020年1月13日）

主な変更点

■ 追加・変更された機能

● 重要な変更：ndb_autoincrement_prefetch_szサーバーシステム変数のデフォルト値が512に増えました。 (Bug #30316314)

● 重要な変更：NDBは2つ以上のレプリカをサポートするようになりました（最大4つまで）。NoOfReplicas=3またはNoOfReplicas=4の設定は、現在、内部テストで完全にカバーされているため、実稼働環境での使用がサポートされています。 (Bug #97479, Bug #97579, Bug #25261716, Bug #30501414, Bug #30528105)

● 重要な変更：TransactionMemoryデータノード設定パラメータが追加され、トランザクション操作のデータノードメモリ割り当ての設定が簡素化されました。継続中のこの部分はトランザクションメモリとローカルデータマネージャー（LDM）メモリのプーリングで機能します。

　この新しいパラメータは、非推奨になった（そのため、NDB Clusterの将来のリリースで削除される可能性がある）古いトランザクションメモリパラメータを置き換えることを目的としています。特に、次のパラメータはTransactionMemoryと互換性がなく、このパラメータが設定されている場合、config.ini設定ファイルに設定できません。
　　・MaxNoOfConcurrentIndexOperations
　　・MaxNoOfFiredTriggers
　　・MaxNoOfLocalOperations
　　・MaxNoOfLocalScans

　これらの互換性のないパラメータをTransactionMemoryと同時に設定しようとすると、クラスター管理サーバーが起動できません。 (Bug #96995, Bug #30344471)

● 重要な変更：このリリースでは、いくつかのNDB Clusterデータノード設定パラメータの最大値またはデフォルト値が変更されました。これらの変更は次のとおりです。
　　・DataMemoryの最大値が1TBから16TBに増やされました。
　　・DiskPageBufferMemoryの最大値も1TBから16TBに増やされました。
　　・StringMemoryのデフォルト値が5パーセントに減らされました。以前、これは25パーセントでした。
　　・LcpScanProgressTimeoutのデフォルト値が60秒から180秒に増やされました。

● パフォーマンス：レプリカからの読み取りは、テーブル書き込みのパフォーマンスよりも非常に低コストでテーブル読み取りのパフォーマンスを大幅に向上し、現在すべてのNDBテーブルに対してデフォルトで有効です。これは、ndb_read_backupシステム変数のデフォルト値が現在ONであり、新しいNDBテーブルを作成する時のNDB_TABLEコメントオプションREAD_BACKUPの値が1であることを意味します。（以前は、デフォルト値はそれぞれOFFと0でした。）

● NDBディスクデータ：ソリッドステートドライブ（特にデータ転送にNVMeを使用するもの）、ディスクデータファイル用の個別の物理ドライブ、またはその両方などの不揮発性メモリデバイスを使用する時、ディスクデータファイルのチェックポイントのレイテンシが短縮されました。この作業の一環として、ここにリストされている2つの新しいデータノード設定パラメータが導入されました。

　　・MaxDiskDataLatencyは、ディスクアクセスの許容レイテンシの最大値を設定し、完了までにこの時間を超えるトランザクションを中止します。
　　・DiskDataUsingSameDisk

　また、このリリースでは、ndbinfoデータベースに3つの新しいテーブルが追加されています。ここにリストされているこれらのテーブルは、ディスクデータのチェックポイント設定のパフォーマンス監視に役立ちます。

　　・diskstatは、過去1秒間のディスクデータテーブルスペースの読み取り、書き込み、ページ要求に関する情報を提供します。
　　・diskstats_1secは、diskstatテーブルで提供される情報と同様の情報を提供しますが、過去20秒ごとに提供します。
　　・pgman_time_track_statsテーブルは、ディスクデータテーブルスペースに影響するディスク操作のレイテンシについて報告します。

● ndb_metadata_syncサーバーシステム変数が追加されました。これにより、いつメタデータの同期が正常に完了したか簡単に知ることができます。この変数をtrueに設定すると、ndb_metadata_checkまたはndb_metadata_check_intervalに設定された値に関係なく、NDBディクショナリとMySQLデータディクショナリ間のすべての変更の即時同期がトリガされます。同期が完了すると、その値は自動的にfalseにリセットされます。 (Bug #30406657)

● 現在、スタックトレースは、データノードの異常終了時にデータノードログに書き込まれます。

● 現在、MySQLデータディクショナリからNDBへのメタデータの自動同期には、NDBテーブルを含むデータベースが含まれます。この機能拡張により、テーブルがNDBに存在し、そのテーブルとそれが属するデータベースが特定のSQLノードに存在しない場合、データベースを手動で作成する必要がなくなりました。代わりに、データベースは、このデータベースに属するすべてのNDBテーブルとともに、SQLノード上に自動的に作成される必要があります。

■ バグ修正

● 互換性のない変更：ndb_restoreは、デフォルトで、共有ユーザーを復元せず、mysql.ndb_sql_metadataテーブルに付与しません。新しいコマンドラインオプション--include-stored-grantsが追加され、この動作は上書きされ、共有ユーザーの復元を有効にし、データとメタデータを付与します。

　この修正の一部として、ndb_restoreはシステムテーブルの順序付けされたインデックスも正しく処理できるようになりました。 (Bug #30237657)

　参照：Bug #29534239, Bug #30459246

● 互換性のない変更：RedoOverCommitCounterデータノード設定パラメータの最小値が0から1に増やされました。RedoOverCommitLimitデータノード設定パラメータの最小値も0から1に増やされました。

　アップグレードする前に、クラスターのグローバル設定ファイルを確認し、これらのパラメータに設定された値に必要な調整を行う必要があります。 (Bug #29752703)

● macOS：MacOSでは、SQLノードは、クラスターを起動する時、バイナリログセットアップフェーズ中に予期せずシャットダウンすることがありました。これは、名前に大文字が使用され、lower_case_table_namesが2に設定されているスキーマがそこに存在する時に発生しました。これにより、メタデータロックの取得が大文字と小文字が正しくないキーを使用して試行され、その後、これらのロックが失敗しました。 (Bug #30192373)

● Microsoft Windows；NDBディスクデータ：Windowsでは、ディスクデータテーブルの使用時にマスター以外のデータノードを再起動すると、TSMANでの障害につながりました。 (Bug #97436, Bug #30484272)

● Solaris：デバッグ時、ndbmtdはSolaris 11.4 SRU 12以降で使用可能なすべてのスワップスペースを消費しました。 (Bug #30446577)

● Solaris：mysql.ndb_sql_metadataテーブルに格納されている数値に使用されるバイト順は、Solaris/Sparcでは正しくありませんでした。これは、ndb_select_allまたはndb_restore --printを使用した時に見られる可能性がありました。 (Bug #30265016)

● NDBディスクデータ：1つのSQLノードでディスクデータテーブルを削除した後、別のSQLノードでINFORMATION_SCHEMA.FILESに対してクエリを実行しようとすると、Waiting for tablespace metadata lockで停止しました。 (Bug #30152258)

　参照：Bug #29871406

● NDBディスクデータ：ALTER TABLESPACE ... ADD DATAFILEは、メタデータロックを取得しようとしている間にハングすることがありました。 (Bug #29871406)

● トランザクションがコミットされた問題に対するNDB 8.0.18での修正は、テーブル定義が途中で変更された場合にトランザクションを早く停止しましたが、getExtraMetadata()によって割り当てられたメモリを解放するテストに失敗しました。現在、このメモリはトランザクションを停止する前に適切に解放されます。 (Bug #30576983)

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

● DBTCでデータを初期化する時の属性バッファの過剰な割り当てにより、予期せずメモリ不足が発生したため、API接続レコードの事前割り当てが失敗しました。 (Bug #30570264)

● NDBが、NDB_STORED_USER権限を持っているがndb_sql_metadataテーブルに見つからないローカルユーザーを更新しようとした場合のエラー処理を改善しました。 (Bug #30556487)

● ALTER TABLE ... ALGORITHM=COPYステートメントの実行中に、その後新しいテーブル名を元のテーブル名に変更した後、元のテーブルを削除する前にトランザクションが失敗すると、mysqldが途中で終了しました。 (Bug #30548209)

● -DWITH_NDBCLUSTERを使用したWindowsでの非MSIビルドは、WiXツールキットがインストールされていない場合、成功しませんでした。 (Bug #30536837)

● NDB 8.0.18のアービトレーションデータノード設定パラメータのndb_config --xml --configinfoからのallowed_values出力は、以前のリリースで取得したものと一致しませんでした。 (Bug #30529220)

　参照：Bug #30505003。

● 部分的なローカルチェックポイントの実装時に導入された誤ったndbrequire()は、START_LCP_REQの受信時にm_participatingLQHがクリアされる必要があると想定しましたが、これは、START_LCP_REQを送信した後、START_LCP_CONF信号を処理する前にマスターに障害が発生した場合、必ずしも当てはまりません。 (Bug #30523457)

● マスターノードがLCP_COMPLETE_REP信号の送信中に停止し、それがすべてのノードではなく一部のノードに送信された場合、ローカルチェックポイントがハングすることがありました。 (Bug #30520818)

● DUMP 9988とDUMP 9989コマンドが追加されました。 (Bug #30520103)

● 管理サーバーは、NODE_FAILREPのすべてのケースを正しく処理しませんでした。 (Bug #30520066)

● SharedGlobalMemoryを0に設定すると、一部のリソースが要求される最小値を満たしませんでした。 (Bug #30411835)

● ndb_restore --rebuild-indexesを--rewrite-databaseと--exclude-missing-tablesオプションと共に実行しても、ターゲットデータベースのどのテーブルにもインデックスが作成されませんでした。 (Bug #30411122)

● ndb_schemaテーブルへのスキーマ操作の書き込みに失敗した時、NDB_SCHEMAオブジェクトの状態はクリアされず、SQLノードはオブジェクトを解放しようとした時にシャットダウンしました。 (Bug #30402362)

　参照：Bug #30371590。

● ディスクページバッファからページを取得中にトランザクションが中止され、ディスクシステムが過負荷になった場合、トランザクションは無期限にハングしました。これにより、再起動がハングし、ノード障害処理が失敗する可能性もありました。 (Bug #30397083, Bug #30360681)

　参照：Bug #30152258。

● エクステントページを同期する時、エクステント同期ページに書き込まれた最後のページのFSWRITECONF信号を受信する時にLCPを処理するCONTINUEB信号がまだ未処理の場合、現在のローカルチェックポイント（LCP）が無期限に停止する可能性がありました。別のページがそのデータページから書き込まれた場合、LCPは再起動されることも可能でした。また、この問題により、PREP_LCPページが本来書き込まれるべきではない時に書き込まれる可能性もありました。 (Bug #30397083)

● エラーAnother node failed during system restart...によるデータノード障害が、部分的な再起動中に発生しました。 (Bug #30368622)

● 自動同期は、特定のメタデータオブジェクトで特定の時間に取得されるロック数の増加を引き起こす可能性がありました。例えば、同期の試行が同じメタデータオブジェクトを含むDDLまたはDMLステートメントと一致していた場合などです。競合するロックは、バックグラウンド同期ではなくユーザーアクションにペナルティを科すNDBデッドロック検出ロジックにつながる可能性があります。自動同期中のすべての排他的メタデータロック取得の試行を（以前許可されていた10秒ではなく）0のタイムアウトを使用するように変更することにより、これを修正しました。これにより、デッドロックの検出が回避され、ユーザーアクションが優先されます。 (Bug #30358470)

● 部分的なローカルチェックポイントの一部としてログファイルグループをドロップし、その結果、次の処理のためにこのブロックによってロックされているページをドロップしている間に、SYNC_EXTENT_PAGES_REQ信号がPGMANによって受信された場合、LCPは、ページが既に削除された後にそのページにアクセスしようとしたため、終了しました。 (Bug #30305315)

● 完了したローカルチェックポイントのクラスターログで誤ったバイト数が報告されました。 (Bug #30274618)

　参照：Bug #29942998。

● 新しいndb_mgmクライアントデバッグコマンドDUMP 2356とDUMP 2357が追加されました。 (Bug #30265415)

● --helpオプションを使用してndb_drop_tableを実行すると、このプログラムはヘルプ出力を生成せずに途中で終了しました。 (Bug #30259264)

● クラスターへの接続を試み、その結果セットアップ中にグローバルスキーマロック（GSL）を取得しようとしたmysqldは、ALTER TABLEステートメントを実行していた時などのGSLが別のmysqldによって既に取得されている時に、ndb-wait-setupの設定を無視し、無期限にハングしました。 (Bug #30242141)

● 自己参照外部キー（つまり、同じテーブルの別の列を参照する外部キー）を含むテーブルがCOPYアルゴリズムを使用して変更された時、外部キー定義は削除されました。 (Bug #30233405)

● MySQL 8.0では、ユーザーによって明示的に提供された外部キーの名前は、SQLレイヤーで自動的に生成され、データディクショナリに保存されます。このような名前は[table_name]_ibfk_[#]という形式で、MySQL 5.7のInnoDBストレージエンジンによって生成される名前と一致します。NDB 8.0.18は、生成された名前も使用するように、NDBの動作の変更を導入しました。しかし、テーブルの名前が変更された場合などのいくつかのケースで、NDBは、SQLレイヤーによって生成されデータディクショナリに保存された名前ではなく、まだ内部でそのような名前を生成し、独自のフォーマットを使用しました。これにより次の問題が発生しました。

　　・SHOW CREATE TABLEの出力とINFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTSの内容の相違
　　・外部キーの不適切なメタデータロック
　　・エラーメッセージでの外部キーの名前の混乱

　現在、NDBは、そのようなケースでは、MySQLサーバーによって提供される名前を使用して、InnoDBによって使用される名前と完全に一致するように、外部キーの名前も変更します。 (Bug #30210839)

　参照：Bug #96508, Bug #30171959。

● 外部キーによって参照されるテーブルの名前が変更された時、参加するSQLノードは、スキーマ配布中にデータディクショナリ内の参照テーブルの外部キー定義を適切に更新しませんでした。 (Bug #30191068)

● 他のデータノードの障害のデータノード処理が適切に同期されない場合があり、2つ以上のデータノードが異なるノードをマスターノードとして認識する可能性がありました。 (Bug #30188414)

● 一部のスキャン操作は、APIノードがNDB 6.4より前のバージョンのソフトウェアを使用しているかどうかを確認するDbtupBuffer.cppに古いアサートが存在することにより、失敗しました。これは不要または正しいものではなくなり、削除されました。 (Bug #30188411)

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

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

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

● SQLノードを以前のリリースシリーズからNDB 8.0にアップグレードする時、内容が読み取られてデータディクショナリにインストールされる.frmファイルには、外部キーに関する情報が含まれていません。これは、外部キー情報がSQLノードのデータディクショナリにインストールされなかったことを意味します。これは、NDBデータディクショナリで利用可能な外部キー情報を使用して、テーブルメタデータのアップグレード中にローカルのMySQLデータディクショナリを更新することで修正されています。 (Bug #30071043)

● --disable-indexesオプションを使用してテーブルを復元すると、誤ったテーブル定義がMySQLデータディクショナリにインストールされました。これは、NDBディクショナリのテーブル定義にパックされたシリアル化ディクショナリ情報（SDI）がテーブルオブジェクトの作成に使用されるためです。SDI定義は、MySQLサーバーを介してDDLの変更が行われた時にのみ更新されます。間違ったテーブル定義をインストールすると、--rebuild-indexesを使用してNDBディクショナリにインデックスが再作成されるまで、テーブルを開けませんでした。

　これは、SDIをNDBディクショナリテーブル情報と比較し、列定義が一致しない場合には失敗するように自動同期を拡張することで修正されています。インデックスのみに関係する不一致は一時的なエラーとして扱われ、問題のテーブルは次の変更検出時に再び検出されます。 (Bug #30000202, Bug #30414514)

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

● バックアップが完了した時にクラスターログに書き込まれたサマリーイベントのデータバイト数が32ビットに切り捨てられました。そのため、ログレコードの数と、このイベントのログに出力されるデータレコードの数との間に大きな不一致がありました。 (Bug #29942998)

● タイムアウトした長いALTER TABLE操作中にmysqldが異常終了することがありました。 (Bug #29894768)

　参照：Bug #29192097。

● SQLノードがNDBに接続した時、そのクラスターに以前に接続したことがあるかどうかがわからなかったため、そのデータディクショナリ情報が単に古いか、完全に無効かを判断できませんでした。この問題は、NDBのndb_schemaテーブルとデータディクショナリのndb_schemaテーブルオブジェクトに一意のスキーマバージョン識別子（スキーマUUID）を実装することで解決されています。現在は、mysqldがSQLノードとしてクラスターに接続する時は常に、そのデータディクショナリに保存されているスキーマUUIDとndb_schemaテーブルに保存されているスキーマUUIDを比較でき、そのため、初めて接続するかどうかを知ることができます。初めての接続の場合、SQLノードはデータディクショナリにある可能性のあるエントリをすべて削除します。 (Bug #29894166)

　参照：Bug #27543602。

● テーブル検出とテーブルメタデータのアップグレードによって生成されるログメッセージを改善しました。 (Bug #29894127)

● ノードあたり10のスレッドがある2ノードクラスターで2つのLDMスレッドを使用すると、各ノードのLDMスレッドの1つがゼロフラグメントのプライマリであるなど、パーティションの不均衡が発生する可能性がありました。1つのLDMのデータファイルには12バイトのデータファイルヘッダーしか含まれていなかったため、このクラスターからマルチスレッドバックアップを復元しようとして失敗し、ndb_restoreは読み取ることができませんでした。空のノードをオンラインで追加した直後にバックアップを取る場合など、他のケースでも同じ問題が発生する可能性がありました。

　これは、サイズが512バイト未満で、バックアップがSTOPPING状態のEOFバックアップデータファイル書き込みに対してODirectが有効になっている時に発生したことがわかりました。これは通常、中断されたバックアップに対してのみ発生しますが、LDMにフラグメントがなかった場合の正常なバックアップに対しても発生する可能性がありました。バックアップにそれを中止させる原因となるエラーが実際に含まれている場合にのみ書き込みがスキップされるように、追加のチェックを導入して問題を修正しました。 (Bug #29892660)

　参照：Bug #30371389。

● NDBテーブルの場合、ALTER TABLE ... ALTER INDEXはALGORITHM=INPLACEでは機能しませんでした。 (Bug #29700197)

● ndb_restoreは、32ビットプラットフォームでのテストに失敗しました。
この問題は、このツールで使用されるスレッドスタックのサイズを64KBから128KBに増やすことで修正されました。 (Bug #29699887)

　References: See also: Bug #30406046.
　参照：Bug #30406046。

● オンラインアップグレード後にテーブルから行を削除している時にDBTUPでエラーが発生したため、クラスターの予期しないシャットダウンが発生しました。 (Bug #29616383)

● ndb_mgmdとndbinfoの実装の一部として使用されるSignalSenderクラスが、不要なSUB_GCP_COMPLETE_REP信号とAPI_REGCONF信号を過剰にバッファし、メモリを不必要に消費する場合がありました。 (Bug #29520353)

　参照：Bug #20075747, Bug #29474136。

● BackupLogBufferSize設定パラメーターの設定が守られませんでした。 (Bug #29415012)

● mysqldが--upgrade=FORCEオプションを使用して実行されると、次の問題が報告されました。
　　　　[Warning]  Table 'mysql.ndb_apply_status' requires repair.
　　　　[ERROR]    Table 'mysql.ndb_apply_status' repair failed.

　これは、--upgrade=FORCEによりブートストラップシステムスレッドはCHECK TABLE FOR UPGRADEを実行するが、ha_ndbcluster::open()はスキーマの同期が完了する前にテーブルを開くことを拒否し、最終的に報告された状態になったためです。 (Bug #29305977)

　参照：Bug #29205142。

● システムの使用可能な共有メモリよりも大きい値に設定されたShmSizeを使用して、明示的なSHM接続を使用すると、mysqldは起動時に無期限にハングし、有効なエラーメッセージを生成しませんでした。 (Bug #28875553)

● ノードがシャットダウンする時は常に、最大グローバルチェックポイント（GCP）コミットラグとGCPセーブタイムアウトが再計算され、データノードの数の変化が考慮されます。これにより、閾値が以前の値を下回った時に、実行可能なノードが意図せずにシャットダウンする可能性がありました。 (Bug #27664092)

　参照：Bug #26364729。

● 子の行を挿入するトランザクションは、その子の親の行を削除するトランザクションと同時に実行できます。この場合、親がない子の行という結果が生じないように、トランザクションの1つを中止する必要があります。

　子の行への挿入をコミットする前に、親の行の読み取りがトリガーされ、親が存在することを確認します。同様に、親の行で削除をコミットする前に、子の行が存在しないことを確認ために読み取りまたはスキャンが実行されます。挿入トランザクションと削除トランザクションが同時に実行された場合は、それらの準備操作とコミット操作は、両方のトランザクションがコミットされるように相互作用する可能性がありました。これは、トリガーされた読み取りがLM_CommittedReadロックを使用して実行されたために発生しました。このロックはこのようなエラーシナリオを防ぐほど強力ではありません。

　この問題は、トリガーされた読み取りの両方により強力なLM_SimpleReadロックモードを使用することで修正されています。LM_CommittedReadロックではなくLM_SimpleReadを使用すると、子の行への挿入と親の行からの削除を同時に行うトランザクションに関連するあらゆる可能性のあるシナリオで、少なくとも1つのトランザクションが中止されます。 (Bug #22180583)

● 同じSQLノードでSELECTとALTER TABLEステートメントを同時に実行すると、それらはロックが解放されるのを待機している時に互いにブロックすることがありました。 (Bug #17812505, Bug #30383887)

● スキーマ同期での障害処理には、バイナリロギングスレッドに警告やエラーをプッシュすることが含まれています。スキーマの同期は、スレッドに警告が蓄積される可能性がある特定の障害の場合にも再試行されます。現在、このような警告とエラーは、スキーマの同期を試みるたびにクリアされます。 (Bug #2991036)

● c_nodeStartSlave.nodeIdをリセットする場合を除き、ノードに障害が発生した場合、ローカルブロックからのINCL_NODECONF信号は無視されるべきです。 (Bug #96550, Bug #30187779)

● Error 1022を返す時、NDBは影響を受けるテーブルの名前を出力しませんでした。 (Bug #74218, Bug #19763093)

　参照：Bug #29700174。

MySQL NDB Cluster 8.0.19リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-19.html

---