追加または変更された機能
- MySQL NDB ClusterJ: MySQL NDB Clusterにおける"table not found"状態の処理が一貫性のために改善されました。以前は、テーブルが見つからない場合、ClusterJはClusterJUserExceptionをスローすることがあり、またClusterJDatastoreExceptionをスローすることもありました。現在、このような全ての条件は、NDBエラーコードをチェックした後、新しい例外クラス ClusterJTableExceptionを使用して報告されます。さらに、新しいプロパティ com.mysql.clusterj.table.wait.msecが導入され、"table not found"状態に対する待機と再試行のループを設定できるようになりました。
この新機能により、NDB Clusterで発生するスキーマ変更もより適切に処理できるようになります。(バグ #37884530)
参考: バグ #37861635、バグ #118032も参照してください。 - MySQL NDB ClusterJ: 単一のSessionFactoryで複数のデータベースを処理できるようになりました。これは、データベース名をその引数として受け取るSessionFactory.getSession()の新しいバリアントを通じて実現されます。この新しい設計では、包括的なSessionFactoryが一連のSessionFactoryオブジェクトを管理します。それぞれが接続の共有プールを介して単一のデータベースに接続するため、同じNDBクラスター内のデータベースへの接続は同じ接続を共有します。
この新機能はデフォルトでは有効になっていませんが、com.mysql.clusterj.multi.databaseプロパティをtrueに設定し、com.mysql.clusterj.connection.pool.sizeを0以外（デフォルトおよび推奨値は1）に設定する必要があります。(バグ #37792409)
参考: バグ #36974092、バグ #115884も参照してください。 - MySQL NDB ClusterJ: ユーザーが同じ接続文字列で異なるデータベース名を持つ2つのClusterJ SessionFactoryオブジェクトを作成すると、2つのデータベースに対して2つの異なるNdb_cluster_connectionオブジェクトが作成され、大量の追加リソースが消費されました。
9.4.0以降では、同じNDBクラスタ内の異なるデータベースに接続する場合、異なるSessionFactoryオブジェクトがグローバル接続プールから同じ基礎になる接続を共有するため、リソース使用量が削減され、パフォーマンスが向上します。この新しい実装では、各NDBクラスターにはシステム名が付けられ、クラスターへの接続はConnection.javaインターフェースによって行われ、新しいSession.getConnection()メソッドによって返されます。詳細はClusterJ API Referenceをご覧ください。(バグ #36974092)
参考: バグ #37792409、バグ #117893も参照してください。 - MySQL NDB ClusterJ: ClusterJも、finalize()メソッドの実装をCleaner APIに置き換えることで改善されました。(バグ #30719755)
- MySQL NDB ClusterJ: session.newInstanceおよびsession.releaseインターフェースを使用する際のClusterJアプリケーションのスケーラビリティが向上しました。DbFactoruImplで維持されるNdbオブジェクトのキャッシュである新しいセッションキャッシュが導入され、アプリケーションのオーバーヘッドが削減され、そのパフォーマンスが向上しました。キャッシュサイズは、com.mysql.clusterj.max.cached.instances設定パラメータを使用して制御できます。このパラメータにより、デフォルトで最大サイズ100のセッションキャッシュが有効になります。(バグ #102510、バグ #32474777)
- NDBノードログのタイムスタンプがマイクロ秒精度で出力されるようになりました。(バグ #37924338)
- MySQL Clusterは、MySQLサーバーで使用されるNDBテーブルの列に対して、明示的なデフォルト式をサポートするようになりました。例えば、次に示すようなNDBテーブルを作成できます:
CREATE TABLE t1 ( i INT DEFAULT 0, c VARCHAR(10) DEFAULT '', f FLOAT DEFAULT (RAND() * RAND()), b BINARY(16) DEFAULT (UUID_TO_BIN(UUID())), d DATE DEFAULT (CURRENT_DATE + INTERVAL 1 YEAR) ) ENGINE=NDBCLUSTER;サポートされている列のデータ型とデフォルトの動作については、Data Type Default Valuesを参照してください。
注意
デフォルトの列値式は、NDB テーブルがMySQLサーバー (mysqld) を使用してアクセスされる場合にのみサポートされ、NDB APIアプリケーションには表示されません。（WL #16678）
バグ修正
- NDBクライアントプログラム: ndb_restoreは、ログを適用する時に、予想どおりに11回に制限するのではなく、一時的なエラーによる再試行を無制限に許可しました。(バグ #37883579)
参考: この問題は、バグ #31546136のリグレッションです。 - NDBクライアントプログラム: DefaultOperationRedoProblemAction=ABORTでバックアップから復元する場合、REDOログ部分の過負荷状態のデータノード処理でエラーが発生し、誤ったエラーコード (この場合は626) がndb_restoreに送り返され、このようなエラーは予期されていなかったためにndb_restoreが途中で終了しました。(バグ #37687485)
参考: この問題は、バグ #13219、バグ #13930、バグ #13980のリグレッションです。 - MySQL NDB ClusterJ: 複数のスレッドが関与している場合、スキーマ変更の処理に失敗しました。この処理を改善するため、session.unloadSchema()が変更され、3つの新しいパブリックメソッド（boolean isStaleMetadata()、boolean isSchemaChangePending()、void awaitSchemaChange()）が定義されました。ClusterJは、スキーマの変更によってドメインタイプハンドラーが無効になったことを検出すると、 ClusterJDatastoreExceptionをスローし、アプリケーションは以下を行えるようになります:
- isStaleMetadata()を呼び出します。
- isStaleMetadata()がtrueを返す場合、例外はスキーマの変更による古いメタデータによって発生しました。その後、スレッドはsession.unloadSchema()を呼び出すことができます。複数のスレッドが関与している場合、unloadSchema()を実行する最初のスレッドがロックを取得し、メタデータを更新します。リフレッシュの進行中にドメインオブジェクトに対してgetDomainTypeHandler()を呼び出す他のスレッドは例外を受け取ります。その後、リフレッシュが完了すると、スレッドはデータ操作を再試行できます。
テーブルメタデータがリフレッシュされると、ClusterJはテーブルメタデータの以前のバージョン番号と現在のバージョン番号を含むログメッセージを書き込みます。 - isStaleMetadata()がfalseを返す場合、ユーザーはisSchemaChangePending()を呼び出して、別のスレッドがメタデータをリフレッシュしようとしているかどうかを確認できます。その場合、ユーザーはawaitSchemaChange()を使用して、データ操作を再試行する前にロックが解除されるのを待つことができます。
（バグ #37861635、バグ #37856493）
- MySQL NDB ClusterJ: Cluster/JでLONGVARCHAR 型とDATE型をプライマリキーとして使用するためのサポートを追加しました。
（バグ #37782638） - MySQL NDB ClusterJ: Java 1.8のjava.util.loggingのパターンを採用することで、ClusterJのロギングが改善されました。このパターンでは、対応するログレベルが有効になっている場合にのみログメッセージが作成されるため、ロギングの効率が向上します。(バグ #37722667)
- MySQL NDB ClusterJ: ユーザーがNOT NULL文字列の列をNULLに設定しようとすると、空文字列が挿入されました。
（バグ #117205、バグ #37476251） - ファイルシステム暗号化におけるパスワード処理を改善しました。
（バグ #37909595） - CREATE TABLESPACEは、指定されたログファイルグループが存在しない場合、エラー 723 No such table existedで拒否されました。エラーでは、SQLステートメントの問題の原因が正しく特定されませんでした。現在、このような状況では、サーバーはエラー 789 Logfile group not foundを発行します。（バグ #37802388）
- 警告 1296 The temporary named table ... already existsで、テーブル名とスキーマ名が間違った順序で表示されました。
（バグ #117918、バグ #37807409）
MySQL NDB Cluster 9.4.0 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql-cluster/9.4/en/news-9-4-0.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。