重要な変更:古いMaxAllocateデータノード設定パラメータは、現在のバージョンのNDBでは効果がありません。このリリースの時点で、非推奨になり、将来のリリースで削除される可能性があります。API:プッシュされたクエリの一部としてプッシュされた条件は、同じプッシュされたクエリ内の祖先テーブルの列を参照できるようになりました。ENGINE=NDBを使用して作成されたテーブルを指定すると、次のようなクエリで条件プッシュダウンを使用できるようになりました。いずれかが含まれる場合があります。比較される値は、長さ、精度、スケールなど、同じタイプである必要があります。SQL標準で指定されている比較セマンティクスに従って実行されます。NULLと比較すると、NULLが返されます。APIに実装されています。新しいNdbScanFilter::cmp_param()メソッドを使用すると、列値とパラメータ値の間で比較を定義できます。アイドル状態のTCP接続を監視および切断する環境では、アイドル状態のクラスタで不要なデータノードのエラーが発生する可能性があり、複数のデータノードでエラーが発生すると、クラスタが計画外にシャットダウンする可能性がありました。この問題を修正するために、データノード間の全ての接続で定期的に(デフォルトでは6000ミリ秒(1分)ごとに1回)送信される新しいキープアライブ信号(GSN_TRP_KEEP_ALIVE)を導入します。これらの信号間の間隔の長さは、このリリースで導入されたKeepAliveSendIntervalデータノードパラメータを設定することで調整できます。このパラメータを0に設定すると、キープアライブ信号を無効にできます。NDBは、これらの信号が受信されたことを確認せず、アカウントで切断も実行しないことに注意してください(これはハートビートプロトコルの責任のままです)。TABLEは、コピーを実行する前後にソーステーブルのフラグメントコミットカウントをチェックするようになりました。TABLEを実行しているSQLノードは、変更されているテーブルへの同時書き込みアクティビティがあったかどうかを判断し、ある場合は操作を終了できます。これにより、データのサイレント損失や破損を回避できます。inconsistency」というエラーで拒否されるようになりました。NDBインデックス統計の作成と更新がデフォルトで有効になりました。メタデータを復元する時に、ndb_restoreは、インデックス統計テーブルがまだ存在しない場合にそれらを作成するようになりました。APIテーブルメソッドは非推奨になりました。8.0は、MySQLデータディクショナリに格納されているテーブルメタデータの読み取りと書き込みにgetExtraMetadata()とsetExtraMetadata()を使用します。Clusterの将来のリリースで削除される予定です。それぞれのデフォルト値が30秒から120秒に増加しました。ClusterとNDBユーティリティを構築する時に生成されたいくつかの警告が削除されました。Windows:Windowsでは、クラスタが64を超えるデータノードを使用するように設定されている場合、データノードを正常に起動できませんでした。API関数が、メモリを適切に解放しませんでした。このコンテキストで欠落しているテーブルは統計テーブルの1つであり、ユーザーにはすぐにはわかりませんでした。existを返します。これはこのリリースで追加されました。バージョン12.2.6を使用して構築されるようになりました。SUMAカーネルブロックで使用されるバッファは、常に複数の信号に対応するとは限りませんでした。DbtupBuffer.cppでは、優先度レベルは1つのパスで現在実行されているものに調整されますが、短い信号には使用されませんでした。これにより、TRANSID_AI信号、SCAN_FRAGCONF信号、または両方の種類の信号が順不同で到着するリスクが発生します。NDBストレージエンジンによってプッシュ結合として実行されたクエリは、次の条件下で、予想よりも少ない行を返しました。・クエリには、firstMatchアルゴリズムを使用して、プッシュ結合として実行されるINまたはEXISTSサブクエリが含まれていました。・サブクエリ自体にも、少なくとも2つのテーブルを使用する外部結合が含まれ、そのうちの少なくとも1つはeq_refアクセスタイプを使用しました。8.0.23で行われた作業の一部には、スキャンの最適化に使用されるTUXスキャンコンテキストの追加が含まれていましたが、スキャンの終了の後にこれが正しく設定されなかった場合がありました。foundというエラーが返されました。この問題は、列の名前の大文字小文字を誤ってを使用したことが原因で発生し、ルックアップを実行する時に、変更されていない元の列の名前を使用するようにすることで修正されました。場合によっては、配列インデックスがNO_OF_BUCKETSを超える可能性がありました。8.0での変更により、トランザクションの操作に必要なリソースが、以前のバージョンのような一時的なリソース(エラー233)ではなく、トランザクションコーディネーターに割り当てられたリソース内に収まらない場合に、永続的なエラー(NDBエラー261)が返されました。これは、一時的なエラーは再試行されるが永続的なエラーは再試行されないNDBレプリケーションでは重要です。トランザクション自体が大きすぎて再構成せずにトランザクションコーディネーターに収まらない場合に、永続的なエラーは適していますが、他のトランザクションによるリソースの消費のためにトランザクションが収まらない場合は、トランザクションは後で、または他のTCインスタンスに収まる可能性があるため、エラーは一時的なものである必要があります。このような場合に返される一時的なエラー(NDBエラー233)は、わずかに異なる意味を持つようになりました。別の操作を割り当てるためにプールされたメモリが不十分です。(以前は、このエラーは、MaxNoOfConcurrentOperationsによって設定された制限に達したことを意味していました。これらの意味(動的割り当てと設定された制限)を混同するのではなく、設定された制限に達した時に返される新しい一時エラー(エラー234)を追加します。CM_REGREF信号から受信したノードIDがMAX_NDB_NODESよりも小さいかどうかを確認するためのndbrequire()をQMGRに追加しました。GET_TABLEID_REQシグナルを処理するためのコードにチェックがないことが報告されました。この問題を修正するために、全てのGET_TABLEID_*シグナルに関連する全てのコードがNDBソースから削除されました。Clusterで使用またはサポートされなくなったためです。QMGRにndbrequire()を追加して、シグナルデータからのプロセスレポートが適切なノードIDを使用するようにしました。内部管理APIを使用する時に、無効なノードタイプを指定できる場合がありました。現在、そのAPIは無効なノードタイプを明確に禁止し、そのような場合をカバーするために“不明な”ノードタイプ(NDB_MGM_NODE_TYPE_UNKNOWN)を定義します。BIT列のストレージを常に正しく初期化するとは限りませんでした。現在のスキーマ操作の参加者として登録されていないノードから偽のスキーマ操作応答を受信すると、SQLノードの計画外のシャットダウンが発生しました。現在、このような場合、参加者として登録されていないノードからの返信は破棄されます。AutomaticThreadConfigなどのBooleanパラメータの値trueおよびfalseは、.cnfファイルに設定された時に正しく処理されませんでした。(この問題は、.iniファイルでのそのような値の処理には影響しませんでした。storage/ndb/src/common/util/version.cppでコンパイラの切り捨ての警告が発生する一時変数の不要なコピーを削除しました。NDBインデックス統計の実装でサポートされる最大インデックスサイズは3056バイトです。NDBCLUSTERが発生しました。このエラーは、スキャン中にTUXカーネルブロックで発生し、スキーマトランザクションが失敗しました。このスキャンは、テーブルにゼロ以外の行数が含まれている時に、インデックスの作成中にトリガーされます。TABLEの実行中にも発生します。TABLEの一部として、またはテーブルに行が含まれていない時にインデックスを作成すると、エラーは返されませんでした。TABLEは上記と同様のエラーを返しました。ハンドラレベルで導入された新しいチェックから適切な警告を返すと同時に、インデックスを作成できるようにすることで、これを修正します。TUXスキャンはエラーを抑制することでこの状況を処理し、代わりに成功を返し、テーブルを空のフラグメントとして効果的に処理します。それ以外の場合、このような場合の動作は変更されず、テーブルに行が含まれているかどうかに関係なく、クライアントに警告が返され、インデックス統計は生成されません。#28714864のリグレッションです。TABLEステートメントはエラーを返しました。これは、このオプションをOFFに設定すると、インデックス統計テーブルの作成が妨げられたためです。現在、これらのテーブルは、--ndb-index-stat-enableの値に関係なく、常にmysqldの起動時に作成されます。NDBスキーマ操作がコーディネーターが処理する前に失われた場合、操作をログに記録したクライアントは、コーディネーターがそれを完了するか中止するのを無期限に待機しました。ndb_mgmdは、1つ以上の無効なオプションを指定して呼び出された時に、説明的なエラーメッセージをクラスタログに書き込むようになりました。NDB接続文字列の一部として使用され、最初のコロンの後に10進数しかないIPv6アドレスが誤って解析され、管理サーバーへの接続に使用できませんでした。同時にユーザーを作成し、このユーザーに異なるMySQLサーバーでNDB_STORED_USER権限を付与すると、これらのサーバーがハングすることがありました。これは、NDBストレージエンジンが有効になっている場合、ユーザーと付与を含む全てのSQLステートメントが評価され、NDB_STORED_USER権限を持つユーザーに影響するかどうかが判断され、その後、一部のステートメントは無視され、一部はステートメントとして全てのSQLノードに配布され、一部はユーザー権限スナップショットを読み取って適用する要求として全てのSQLノードに配布されるためです。これらのスナップショットは、mysql.ndb_sql_metadataテーブルに保存されます。1つのSQLステートメントに制限されているステートメントの更新とは異なり、スナップショットの更新には、ユーザーごとに最大7つのSQLステートメントを含めることができます。分散ユーザーの管理中にNDBバイナリロギングスレッドでロックを待機すると、スレッドがローカルACLキャッシュで排他ロックを待機している時に、デッドロックが発生する可能性があります。NDB_STORED_USERスナップショットの更新を明示的にロックすることで、この問題を修正します。スナップショットの配布は、ndb_sql_metadataテーブルの1つの行でグローバル読み取りロックを保持しながら実行されるようになりました。(以前は、ステートメントとスナップショットの両方の配布は、ロックなしで非同期に実行されていました。)現在、スレッドが最初の試行でこのロックを取得しない時、警告が発生し、デッドロックが防止されます。タイプに関係なく、アクセスが許可された指定APIノード以外のノードからのトランザクションが許可されていないため、クラスタがシングルユーザーモードの場合、インデックス統計を作成または更新できませんでした。これにより、インデックス統計に関連するトランザクションの開始を担当するデータノードがそうすることができなくなりました。シングルユーザーモードで制約を緩和し、データノードからのトランザクションを許可する(他のAPIノードからのトランザクションは許可しない)ことで、この問題に対処します。複数の管理ノードを開始する場合、最初のそのようなノードは、設定をコミットする前に他のノードが開始するのを待ちますが、これはユーザーに明示的に伝達されませんでした。全ての管理ノードを起動せずにデータノードを起動した場合、設定がまだコミットされていないためにノードIDが割り当てられていないことをユーザーに示すことはありませんでした。現在、このような場合、管理ノードは、クラスタが複数の管理ノードを使用するように設定されていること、およびそのようなノードが全て開始されていることを確認するようにユーザーに通知するメッセージを出力します。Server(SQLノード)の実行したままの時にクラスタが再起動された場合を処理するために、インデックス統計スレッドは最初のクラスタの開始または再起動が発生した時に通知されます。インデックス統計スレッドは、新しいNdbオブジェクトの作成と様々なシステムオブジェクトのチェックを強制しました。これは、MySQLサーバーが最初のクラスタの開始と同時に開始され、Ndbオブジェクトの不要な再作成につながった場合は不要です。このような場合、Ndbオブジェクトを強制的に再作成するのではなく、リスナーのみを再起動することでこれを修正します。ノードログのエラーによって書き込まれた一部のエントリに表示されていた余分なスペースを削除しました。ndb_restoreは、メタデータが--disable-indexesで既に復元された後にデータを復元する時に、--disable-indexesを使用するように警告を発しました。--disable-indexesを使用してデータを復元する前にメタデータを復元する場合、ターゲットスキーマのテーブルにはインデックスがありません。このオプションを使用してデータを復元する時に、ターゲットテーブルにインデックスがないことを確認し、テーブルにすでにインデックスがある場合にのみ警告を出力するようになりました。binlogインジェクタースレッドは、ストレージエンジンから受信したデータ変更イベントの処理中にエラーを検出するようになりました。エラーが検出された場合、スレッドはエラーメッセージをログに記録して自身を再起動し、再起動の一部として、例外、インシデント、またはLOST_EVENTSエントリがバイナリログに書き込まれます。この特別なエントリは、バイナリログが不完全であることをレプリケーションアプライヤに示します。--disable-indexesを使用してメタデータの復元を実行した場合、これらのインデックスに依存するインデックスまたは外部キーを作成する試みはありませんでしたが、オプションなしでndb_restoreを使用すると、インデックスと外部キーが作成されました。後でデータの復元中に--disable-indexesが使用された場合、NDBは前の手順で作成されたインデックスを削除しようとしましたが、削除されなかった外部キーのインデックスに依存しているため、インデックスの削除操作の失敗を無視しました。これにより、既存の外部キーを作成しようとした時に、インデックスの再構築中に問題が発生しました。ndb_restoreを次のように修正します。・--disable-indexesを使用すると、ndb_restoreはバックアップから復元された外部キーを全て削除するようになりました。・ndb_restoreは、インデックスを削除しようとする前に、インデックスの存在をチェックするようになりました。ndb_restoreの--ndb-nodegroup-mapオプションが意図したとおりに機能せず、それをサポートするコードが削除されました。このオプションは何も実行しないようになり、設定された値は全て無視されます。イベントロガーによって表示されるイベントバッファステータスメッセージが改善されました。パーセンテージは、表示する必要がある場合にのみ表示されるようになりました。最大サイズが定義されていない場合、印刷出力にはmax=unlimitedと表示されます。BufferedLogHandlerの不完全なデストラクタが原因で、MgmtSrvr::configure_eventloggerで作成されたファイルハンドルとFileLogHandlerオブジェクトがリークされました。実行中のndb_mgmdでクラスタ設定が変更される度に、クラスタログが再度開かれ、ファイルハンドルがリークし、テストプログラムの問題やその他の問題が発生する可能性がありました。--configdirが.として指定されていたが、DataDir以外の現在の作業ディレクトリを使用している場合、バイナリ設定は現在のディレクトリではなくDataDirに作成されました。DataDirに既存のバイナリ設定がある場合、ndb_mgmdは開始されませんでした。ndb_mgmdにパスをチェックさせ、--configdirに相対パスが指定されている場合は開始を拒否することで、これを修正します。NDBCLUSTERがクラスタイベントを受信するためのサブスクリプションを作成できなかった時に、メモリリークが発生しました。提供されたイベントデータの所有権は引き継がれることになっていますが、実際には作成が成功した場合にのみ発生します。それ以外の場合は、提供されたイベントデータが単に失われます。--config-fileも指定されている場合、ndb_mgmdは--ndb-connectstringオプションを無視します。両方のオプションが使用されると、この影響に対する警告が発行されるようになりました。Clusterでは効果がありません。現在、両方のパラメータは非推奨であり、クラスタ設定ファイルにいずれかが存在すると警告が発生します。将来のリリースで削除されると思っておく必要があります。LIMIT句を使用して一括UPDATEステートメントを実行すると、NDBからエラーが返された時にデバッグアサーションが発生しました。特定のシナリオではこの時点でエラーが返されると予想されるため、NDBテーブルのアサーションを緩和することでこれを修正します。EditionsMySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。