MySQL NDB Cluster 8.0.26 GA版（リリース日：2021年7月20日）

主な変更点

■ 追加・変更された機能

● NDB Cluster API：NDBで使用されるNode.jsのバージョンが12.22.1にアップグレードされました。（バグ #32640847）

● NDB Cluster API：NdbScanFilter::setSqlCmpSemantics()メソッドをNDB APIに追加しました。以前は、NdbScanFilterは常にNULLをそれ自体と等しいものとして扱っていたため、NULL == NULLはBoolean TRUEとして評価されます。これは、NULL == NULLがNULLを返すことを要求するSQL標準に準拠していません。新しいメソッドを使用すると、特定のNdbScanFilterインスタンスの存続期間中、従来の動作をオーバーライドし、代わりにSQL準拠のNULL比較を実施できます。

● ndb_restoreは、次のようにNULL列とNOT NULL列の間の変換をサポートするようになりました。

　　・NULL列をNOT NULLとして復元するためには、--lossy-conversionsオプションを使用します。
　　　列にNULL行が存在すると、ndb_restoreが発生し終了します。

　　・NOT NULL列をNULLとして復元するためには、--promote-attributesオプションを使用します。

　（バグ #32702637）

● IPv4 (4)またはIPv6 (6)のDNSリゾルバーのアドレス指定設定を制御するPreferIPVersion設定パラメータが追加されました。デフォルトは4です。このパラメータは、全てのTCP接続で同じである必要があります。この理由から、それはクラスタグローバル設定ファイルの[tcp default]セクションでのみ設定すべきです。（バグ #32420615）

■ バグ修正

● パッケージング：ndb-commonのマニュアルページが削除され、そこに含まれる情報が他のマニュアルページに移動しました。（バグ #32799519）

● パッケージング：mysqlbinlogユーティリティはNDB Cluster Dockerイメージに含まれていませんでした。（バグ #32795044）

● NDBレプリケーション：NDBレプリケーションに参加しているSQLノードでNDB_STORED_USERを使用すると、付与の取り消しと復元が繰り返されることがありました。このような場合にACL操作を実行する時に、log_slave_updatesと元のserver_idが正しく処理されるようにすることで、これを修正します。（バグ #32832676）

● NDBレプリケーション：255個のSQLノードでクラスタを開始すると、一部のmysqldプロセスがスキーマ配布を適切に初期化しませんでした。これにより、バイナリログのセットアップが失敗し、SQLノードが動作可能になることはありませんでした。このエラーは、スキーマの変更をサブスクライブする時に発生しました。mysql.ndb_schemaテーブルのNdbEventOperationの設定が失敗しました。さらに、MySQLサーバーはmysql.ndb_schema_resultテーブルのサブスクリプションも設定する必要があるため、各MySQLサーバーには2つのリソースが必要です。

　この問題を修正するために、MaxNoOfSubscriptions設定パラメータの有効なデフォルトは、2 * MaxNoOfTablesとしてではなく、2 * MaxNoOfTables + 2 * [APIノードの数]として扱われるようになりました。（バグ #32380993）

● NDB Cluster API：Node.jsアダプタは、文字セットと照合番号を常に正しく処理するとは限りませんでした。（バグ #32742521）

● NDB Cluster API：MGM APIのNdb_logevent_typeにNDB_LE_EventBufferStatus3ログイベントタイプを追加しました。これは、合計、最大、および割り当てられたバイトを64ビット値として処理するNDB_LE_EventBufferStatusタイプの拡張です。

　（バグ #32381666）

● NDBCLUSTERエンジンにプッシュ可能な条件が、ビューまたはテーブルのサブクエリの一部として参照された場合、テーブルにプッシュダウンされませんでした。（バグ #32924533）

● ndbxfrmにndbclientライブラリが含まれているために、ダイナミックリンクを使用したNDB for DockerのRPMビルドが完了しませんでした。現在、ndbxfrmは、代わりに内部のndbgeneralおよびndbportlibライブラリを使用します。

　この修正の一環として、ndb_restoreはndbgeneralおよびndbportlibに対してもリンクするようになりました。（バグ #32886430）

● NDBは、2つの数値の最小値と最大値を決定するために、独自の内部マクロの代わりにstd::min()とstd::max()を使用するようになりました。（バグ #32854692）

● ndb_restoreによって出力された一部のエラーメッセージは、エラー情報のためにすでに閉じられているトランザクションにアクセスしようとしたため、計画外の終了が発生しました。（バグ #32815725）

● NDBエラーの418（Out of transaction buffers in LQH...）、419（Out of signal memory...）、805（Out of attrinfo records in tuple manager...）のエラーメッセージは全て、LongSignalMemoryの増加を示していますが、その名前の設定パラメーターはありません。これらの3つのエラーメッセージは全て、代わりにLongMessageBufferパラメータを参照するように修正されています。（バグ #32797240）

● NDBテーブルのCREATE TABLEが失敗すると、一般的なエラーメッセージ（ERROR HY000: Can't create table 'tbl'）が返され、追加のより具体的なエラーメッセージが警告としてプッシュされることがよくあります。これに気づかず、一般的なメッセージのみを見る可能性があるユーザーを支援するために、SHOW WARNINGSステートメントに関するリマインダーテキストを一般的なエラーメッセージに追加して、特定の問題をより迅速に解決するのに役立つ可能性のある追加情報を取得するようユーザーに促します。（バグ #32788231）

● MySQLハンドラエラーコードにマップされていないNDBエラーは、通常、エラー1296または1297としてMySQLユーザーに表示され、基になるNDBエラーコードを示すメッセージが表示されます。この動作の1つの例外は、COMMITエラー（ndbcluster_commit()から発生）です。通常のNDBエラーは4350 Transaction already abortedです。MySQLは最終的にこれをCライブラリのstrerror()に渡し、Unknownエラーなどのプレフィックスが付けられていましたが、このプレフィックスの正確な形式は、使用されているlibcのバージョンとのプラットフォーム固有の違いによって異なりました。

　SQL State 25000 Invalid Transaction Stateに関連付けられた新しいハンドラエラーHA_ERR_TX_FAILEDと新しいクライアントエラーER_TRANSACTION_FAILEDの両方を作成することにより、これを修正します。（バグ #32763179）

　参照：バグ #30264401。

● --print-full-configオプションを指定して開始すると、ndb_mgmdは、Address already in useというエラーで終了しました。これは、このオプションが指定されている場合に空きポートの検証をスキップすることで修正されます。（バグ #32759903）

● ndbinfo.cluster_locksテーブルに対してクエリを実行する時にクラスタログに生成された不要なプリントアウトを削除しました。（バグ #32747486）

● DbUtilクラスは、MySQLクライアントライブラリを使用するスレッドがそれを終了した時にmysql_library_end()を呼び出さず、mysql_thread_end()を呼び出してスレッドのローカルリソースを解放しませんでした。（バグ #32730214）

● 同じDbUtilインスタンスを使用してクエリを2回目実行すると、DbUtilでメモリリークが発生しました。接続チェックは既存のMYSQLインスタンスを検出せず、解放せずに置き換えました。（バグ #32730047）

● NDBテーブルが使用するパーティションの数を判別している時にエラーを返すと、示されたファイルが存在しなかったにもかかわらず、MySQLサーバーがtable.frmファイルの誤った情報をエラーログに書き込みました。これにより、MySQLサーバーが実際にNDBに接続されていない時に、ユーザーがNDBテーブルを開こうとした場合に、エラーログがフラッディングするという問題も発生しました。

　MySQLデータディクショナリからロードされた値をNDBからフェッチせずに使用するようにパーティションの数を決定する関数を変更することで、これを修正します。これにより、テーブルを開く時のラウンドトリップも1回節約できます。アップグレードのためにテーブルが開かれる特殊なケースでは、アップグレードコードパスのNDBから値をフェッチすることにフォールバックします。（バグ #32713166）

● CREATE NODEGROUPで重複ノードIDを使用すると（例えば、CREATE NODEGROUP 11, 11）、クラスタの計画外のシャットダウンが発生する可能性があります。このコマンドに重複するノードIDが含まれていると、エラーが発生するようになりました。（バグ #32701583）

● 場合によっては実行が非常に遅くなる可能性があったndbinfo.cluster_locksテーブルに対するクエリのパフォーマンスが向上しました。（バグ #32655988）

● 引数の解析、エラー報告、およびndbxfrmからのクラスを使用した暗号化ファイルのオープンに関連してndb_print_backup_fileで見つかった多くの問題を修正しました。（バグ #32583227）

● ディレクトリunittest/ndbは、使用されなくてもビルドプロセスによって生成されました。このディレクトリは、NDBのビルド時に作成されなくなりました。（バグ #32553339）

● メインメモリにREDOログ用に保持されているログレコードが1秒以内にREDOログファイルに書き込まれるようにするために、DBLQHのタイムスーパーバイザーは書き込み前にREDOログ部分のロックを取得します。以前の問題の修正により、REDOログファイルがまだ開かれておらず、書き込みの準備ができていない時に、continueBシグナル（その修正の一部として導入された）が送信され、ロックを解除せずに戻ってきました。このような場合、REDOログファイルが開いて書き込みの準備ができるのを待つ前に、取得したロックを解放するようになりました。（バグ #32539348）

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

● バイナリログインジェクタースレッドでNDBからイベントを受信するために使用されるNdbオブジェクトをndb_eventbuffer_max_allocの値で更新することは、エポックごとに1回値を更新するだけで十分な場合に、各エポックの開始時と1つのイベントを処理した後の両方で実行されました。

　各イベントの処理中にグローバル値から更新しないことでこれを修正します。これにより、各イベント処理ループ中に必要な作業量が削減されます。（バグ #32494904）

● イベントストリームからの読み取り中にblob列の全てのblobパーツを見つけられなかったことは適切に処理されませんでした。そのため、呼び出し元のコピーアウトバッファ内のデータが不完全になり、呼び出し元にエラーが返されませんでした。

　イベントAPIのユーザーは、データがblob列を持つテーブルのために受信されたことが通知されると、blob全体を保持するのに十分な大きさのバッファを作成し、関数を呼び出してイベントストリームからblob列を読み取ります。ほとんどのblobタイプは、いくつかの小さなパーツとしてNDBに格納されます。イベントストリームからblob列のblobデータを読み取るためには、バッファリングされたイベントデータをトラバースして、blobパーツを検索し、各パーツを提供されたバッファにコピーする必要があります。ブロブ列に関連付けられたバッファリングされたイベントデータの各部分は、必要なブロブ部分のデータが含まれているかどうかを確認するために調べられます。ブロブパーツが見つかると、呼び出し元によって提供された元のオフセットでバッファにコピーされます。

　ブロブパーツを見つける関数は、一度に1つ以上のブロブパーツをコピーできます。この関数は通常、ブロブパーツをまとめる時に数回呼び出されます - まず最初のブロブパーツを、次に全てのパーツを（一度にいくつか）、最後の部分で残りを見つけます。関数がバッファリングされたイベントデータで要求された全てのBLOBパーツを見つけない場合、これにより、いくつかの異なるケースのいずれかが原因で発生する可能性のある不整合が発生します - 全てのパーツが送信されていない可能性があり、それにより受信したパーツが間違った場所に保存されている可能性がある場合、blobパーツをまとめるロジックに問題があるか、他の問題がある可能性があります。不整合は、見つけられたblobパーツの数と、今回コピーするように要求された数を比較することによって検出されます。

　この問題は、一部のALTER TABLE操作の実行中に発生する可能性のある計画外のSQLノードシャットダウンの問題を調査している時に見つかりました。ここで、デバッグコンパイルされたmysqldは、欠落しているblobパーツに関する情報を出力した後にアサートしました。手動のコード検査では、リリースコンパイルされたバイナリが不完全なバッファを呼び出し元に返すだけであることが示されています。この問題は、以前の同様の問題に対処する際にも見られました。

　要求されたblobパーツが見つからない場合は常に、NdbEventOperationImpl::readBlobParts()からエラーを返すことで、この問題を修正します。これは重大な不整合であるため、この問題が検出された時に提供される印刷出力も拡張します。拡張された印刷出力のサンプルを次に示します。

　　　= print_blob_part_bufs =============================
　　　part_start: 0, part_count: 15
　　　table: { id: 13, version: 2, name: 't1' }
　　　column: { attrid: 1, name: 'b' }
　　　blob parts table: { id: 14, version: 2, name: 'NDB$BLOB_13_1' }
　　　available buffers: {
　　　[0]*:  part_number: 1, size: 2000, offset: 2000
　　　[1]*:  part_number: 14, size: 2000, offset: 28000
　　　[2]*:  part_number: 7, size: 2000, offset: 14000
　　　[3]*:  part_number: 5, size: 2000, offset: 10000
　　　[4]*:  part_number: 3, size: 2000, offset: 6000
　　　[5]*:  part_number: 0, size: 2000, offset: 0
　　　[6] :  part_number: 15, size: 2000, offset: 30000
　　　[7]*:  part_number: 13, size: 2000, offset: 26000
　　　[8]*:  part_number: 12, size: 2000, offset: 24000
　　　[9]*:  part_number: 11, size: 2000, offset: 22000
　　　[10]*:  part_number: 10, size: 2000, offset: 20000
　　　[11]*:  part_number: 9, size: 2000, offset: 18000
　　　[12]*:  part_number: 8, size: 2000, offset: 16000
　　　[13]*:  part_number: 6, size: 2000, offset: 12000
　　　[14]*:  part_number: 4, size: 2000, offset: 8000
　　　[15]*:  part_number: 2, size: 2000, offset: 4000

　（バグ #32469090）

　参照：バグ #32405937、バグ #30509284。

● ノードは、再起動中に、リカバリが終了するまで待機するのではなく、リカバリを完了する前にバックアップに参加することを許可されていました。（バグ #32381165）

● NDB ClusterソースからNDB_WIN32を削除しました。この定義は、かつてはWindows専用に条件付きでコンパイルされるようにコードを区切ることを目的としていましたが、長い間、この目的のために_WIN32に取って代わられていました。（バグ #32380725）

● NDBバックアップの実行中にディスク容量が不足すると、クラスタが計画外にシャットダウンする可能性がありました。（バグ #32367250）

● インデックス統計スレッドは、バイナリログインジェクタースレッドに依存して、初期システム再起動についてそれに通知します。次に、インデックス統計スレッドは（非同期に）Ndbオブジェクトをリサイクルし、そのシステムテーブルを作成します。タイミングによっては、NDBテーブルが書き込み可能であった一定時間、インデックス統計スレッドが要求を処理する準備ができていない可能性がありました。また、これにより、データノードパラメータIndexStatAutoCreateが1に設定されている場合、保存された許可のセットアップ中に問題が発生しました。

　これを2つの方法で修正します。

　　・信号をバイナリログ設定のインデックス統計スレッド部分に送信して、タイムリーに
　　　検出されるようにします。

　　・このような場合、バイナリログの設定を強制的にインデックス統計機能が設定されるまで
　　　待機させます。

　（バグ #32355045）

● NoOfReplicasを1に等しく設定し、config.iniファイルで72を超えるデータノードを定義して、ndb_mgmdを開始することができました。現在、管理サーバーはこの状態をチェックし、見つかった場合は起動を拒否します。（バグ #32258207）

● NodeGroupパラメータのconfig.iniに無効な値を設定してndb_mgmdを開始することができました。その後、その値を使用するデータノードプロセスは開始できませんでした。現在このような場合、管理サーバーは起動を拒否し、適切なエラーメッセージを表示します。（バグ #32210176）

● 名前の大文字と小文字のみを変更する列のインプレース名前変更を実行したALTER TABLE t1 ALGORITHM=INPLACE, RENAME COLUMN B to bなどのステートメントは成功しましたが、その変更はNDBディクショナリに反映されませんでした（例えば、ndb_descの出力で）。NDBディクショナリが常にSQLステートメントで指定された大文字と小文字と一致し、これがMySQLデータディクショナリに格納されている名前と一致するようにすることで、この問題を修正します。（バグ #31958327）

● イベントバッファの輻輳は、バイナリロギングを実行していたSQLノードの計画外のシャットダウンにつながる可能性がありました。代わりに、（非推奨のpollEvents()メソッドではなく）Ndb::pollEvents2()を使用してこのようなエラーを適切にキャッチして処理するようにバイナリログハンドラーを更新することで、これを修正します。（バグ #31926584）

● ndb_importの--resumeオプションは、--statsオプションも指定されていない限り、正しく機能しませんでした。（バグ #31107058）

● 挿入中または更新中に重複キーエラーが進行中のトランザクションを停止しないことをハンドラーに通知するためにINSERT IGNOREおよび他の同様のSQLステートメントで使用されるフラグのスコープの以前の変更を元に戻しました。現在、これらのフラグは、以前と同様に、全ての書き込み行イベントの後にクリアされます。 （バグ #27538524）

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

● NDBCLUSTERは、MY_BITMAPタイプのビットマップを使用して、様々なコンテキストで使用される列を追跡します。パフォーマンスが重要な短期間のコードで使用する場合、これらはコンパイル時に（固定）サイズが定義されるビットバッファで初期化されます。これらのバッファのサイズは複数の方法で計算されたため、コピーアンドペーストエラー、バッファが十分に大きいかどうかの不確実性、および過剰なスペースの割り当ての可能性が発生する可能性がありました。

　バッファが保持する必要のあるビット数をテンプレート引数として受け取る内部Ndb_bitmap_bufクラスを実装し、静的ビットマップバッファの全てのオカレンスをNdb_bitmap_bufのインスタンスに変更することで、これを修正します。これにより、バッファが大きすぎる条件プッシュダウンコードで数バイトも節約されます。 （バグ #27150799）

● WHERE句がBLOB列を参照しているDELETEステートメントが正しく実行されませんでした。（バグ #13881465）

● データノードと管理ノードのログの分析は、全てのログメッセージにタイムスタンプが含まれているわけではないという事実によって妨げられることがありました。これは、いくつかの異なるログ関数（printf、fprintf、ndbout、ndbout_c、<<オーバーロードなど）を、各ログメッセージをYYYY-MM-DD HH:MM:SS形式のタイムスタンプで開始する既存のEventLoggerメカニズムに置き換えて標準化することで修正されます。

　参照：バグ #21441915、バグ #30455830。

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

---