付録 A MySQL 5.6 のよくある質問

目次

A.1 MySQL 5.6 FAQ: 全般
A.2 MySQL 5.6 FAQ: ストレージエンジン
A.3 MySQL 5.6 FAQ: サーバー SQL モード
A.4 MySQL 5.6 FAQ: ストアドプロシージャーおよびストアドファンクション
A.5 MySQL 5.6 FAQ: トリガー
A.6 MySQL 5.6 FAQ: ビュー
A.7 MySQL 5.6 FAQ: INFORMATION_SCHEMA
A.8 MySQL 5.6 FAQ: 移行
A.9 MySQL 5.6 FAQ: セキュリティー
A.10 MySQL 5.6 FAQ: MySQL Cluster
A.11 MySQL 5.6 FAQ: MySQL の中国語、日本語、および韓国語の文字セット
A.12 MySQL 5.6 FAQ: コネクタおよび API
A.13 MySQL 5.6 FAQ: レプリケーション
A.14 MySQL 5.6 FAQ: MySQL エンタープライズスケーラビリティースレッドプール

A.1 MySQL 5.6 FAQ: 全般

A.1.1. 本番で使用 (GA) できる MySQL はどのバージョンですか。
A.1.2. 開発 (GA ではない) バージョンの状況を教えてください。
A.1.3. MySQL 5.6 ではサブクエリーを実行できますか。
A.1.4. MySQL 5.6 では複数テーブルへの挿入、更新、および削除を実行できますか。
A.1.5. MySQL 5.6 にはクエリーキャッシュはありますか。それはサーバー、インスタンス、またはデータベースで動作しますか。
A.1.6. MySQL 5.6 にはシーケンスはありますか。
A.1.7. MySQL 5.6 には秒の小数部が返される NOW() 関数はありますか。
A.1.8. MySQL 5.6 はマルチコアプロセッサで動作しますか。
A.1.9. mysqld の複数のプロセスが表示されるのはなぜですか。
A.1.10. MySQL 5.6 は ACID トランザクションを実行できますか。

A.1.1.

本番で使用 (GA) できる MySQL はどのバージョンですか。

MySQL 5.6、MySQL 5.5、MySQL 5.1、および MySQL 5.0 は、本番での使用がサポートされます。

MySQL 5.6 は MySQL 5.6.10 で一般提供 (GA) ステータスとなり、2013 年 2 月 5 日に本番使用のためにリリースされました。

MySQL 5.5 は MySQL 5.5.8 で一般提供 (GA) ステータスとなり、2010 年 12 月 3 日に本番使用のためにリリースされました。

MySQL 5.1 は MySQL 5.1.30 で一般提供 (GA) ステータスとなり、2008 年 11 月 14 日に本番使用のためにリリースされました。

MySQL 5.0 は MySQL 5.0.15 で一般提供 (GA) ステータスとなり、2005 年 10 月 19 日に本番使用のためにリリースされました。MySQL 5.0 のアクティブな開発は終了しました。

A.1.2.

開発 (GA ではない) バージョンの状況を教えてください。

MySQL は、本番前品質機能を導入してリリース品質に安定化させるマイルストーンリリースモデルに従っています (http://dev.mysql.com/doc/mysql-development-cycle/en/index.html を参照してください)。このプロセスは繰り返され、各リリースが本番前ステータスおよびリリース品質ステータスの間を循環します。特定のリリースのステータスを確認するには、変更ログをチェックしてください。

MySQL 5.4 は開発シリーズでした。このシリーズへの作業は終了しました。

MySQL 5.7 は、前述のマイルストーンリリース方式を使用して、アクティブに開発されています。

MySQL 6.0 は開発シリーズでした。このシリーズへの作業は終了しました。

A.1.3.

MySQL 5.6 ではサブクエリーを実行できますか。

はい。セクション13.2.10「サブクエリー構文」を参照してください。

A.1.4.

MySQL 5.6 では複数テーブルへの挿入、更新、および削除を実行できますか。

はい。複数テーブルへの更新の実行に必要な構文については、セクション13.2.11「UPDATE 構文」を参照してください。複数テーブルでの削除の実行に必要な構文については、セクション13.2.2「DELETE 構文」を参照してください。

複数テーブルへの挿入は、FOR EACH ROW 句の BEGIN ... END ブロック内に複数の INSERT ステートメントが含まれているトリガーを使用して実行できます。セクション20.3「トリガーの使用」を参照してください。

A.1.5.

MySQL 5.6 にはクエリーキャッシュはありますか。それはサーバー、インスタンス、またはデータベースで動作しますか。

はい。クエリーキャッシュはサーバーレベルで動作し、元のクエリー文字列と一致する完全な結果セットがキャッシュされます。まったく同じクエリーが発行された (これは特に Web アプリケーションでよく行われます) 場合、解析または実行を行う必要はありません。結果がキャッシュから直接送信されます。さまざまなチューニングオプションを使用できます。セクション8.9.3「MySQL クエリーキャッシュ」を参照してください。

A.1.6.

MySQL 5.6 にはシーケンスはありますか。

いいえ。ただし、MySQL には AUTO_INCREMENT システムがあり、MySQL 5.6 のマルチマスターレプリケーションセットアップで挿入を処理することもできます。auto_increment_increment および auto_increment_offset システム変数を使用して、各サーバーがほかのサーバーと競合しない自動インクリメント値を生成するように設定できます。auto_increment_increment にはサーバーの数より大きい値を指定し、各サーバーが一意のオフセットを持つようにします。

A.1.7.

MySQL 5.6 には秒の小数部が返される NOW() 関数はありますか。

いいえ。これは MySQL のロードマップにローリング機能として挙がっています。これは、フラッグシップ機能ではありませんが、開発時間が許すかぎり今後実装されることを意味します。特定の顧客の要求によって、このスケジュールが変更されることがあります。

ただし、MySQL では小数部がある時間文字列が解析されます。セクション11.3.2「TIME 型」を参照してください。

A.1.8.

MySQL 5.6 はマルチコアプロセッサで動作しますか。

はい。MySQL は完全にマルチスレッド化されており、オペレーティングシステムでそれらがサポートされている場合、複数の CPU が使用されます。

A.1.9.

mysqld の複数のプロセスが表示されるのはなぜですか。

LinuxThreads を使用している場合は、少なくとも 3 つの mysqld プロセスが実行されていることが表示されます。これらは実際にはスレッドです。LinuxThreads マネージャーのための 1 つのスレッド、接続を処理するための 1 つのスレッド、およびアラームおよびシグナルを処理するための 1 つのスレッドがあります。

A.1.10.

MySQL 5.6 は ACID トランザクションを実行できますか。

はい。MySQL の現在のすべてのバージョンでトランザクションがサポートされます。InnoDB ストレージエンジンは、行レベルのロック、マルチバージョン、非ロックの反復可能読み取り、および 4 つのすべての SQL 標準分離レベルを持つ、完全な ACID トランザクションを提供しています。

NDB ストレージエンジンは、READ COMMITTED トランザクション分離レベルのみをサポートしています。

A.2 MySQL 5.6 FAQ: ストレージエンジン

A.2.1. MySQL のストレージエンジンの完全なドキュメントはどこで入手できますか。
A.2.2. MySQL 5.6 に新しいストレージエンジンはありますか。
A.2.3. MySQL 5.6 で削除されたストレージエンジンはありますか。
A.2.4. ARCHIVE ストレージエンジンに固有の利点は何ですか。

A.2.1.

MySQL のストレージエンジンの完全なドキュメントはどこで入手できますか。

第15章「代替ストレージエンジンを参照してください。この章には、MySQL Cluster に使用される NDB ストレージエンジンを除く、MySQL のすべてのストレージエンジンについての情報が含まれています。NDB については、第18章「MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4で説明しています。

A.2.2.

MySQL 5.6 に新しいストレージエンジンはありますか。

MySQL 5.1 ではオプションの InnoDB Plugin の機能が組み込みの InnoDB ストレージエンジンに取り込まれたため、Barracuda ファイル形式、InnoDB テーブルの圧縮、パフォーマンスのための新しい構成オプションなどの機能を活用できます。詳細は、第14章「InnoDB ストレージエンジンを参照してください。また、InnoDB は新しいテーブルのデフォルトのストレージエンジンになりました。詳細は、セクション14.1.1「デフォルトの MySQL ストレージエンジンとしての InnoDB」を参照してください。

A.2.3.

MySQL 5.6 で削除されたストレージエンジンはありますか。

いいえ。

A.2.4.

ARCHIVE ストレージエンジンに固有の利点は何ですか。

ARCHIVE ストレージエンジンは、インデックスのない大量のデータを格納するのにもっとも適しています。フットプリントが非常に小さく、テーブルスキャンを使用して選択が実行されます。詳細は、セクション15.5「ARCHIVE ストレージエンジン」を参照してください。

A.3 MySQL 5.6 FAQ: サーバー SQL モード

A.3.1. サーバー SQL モードとは何ですか。
A.3.2. サーバー SQL モードはいくつありますか。
A.3.3. サーバー SQL モードを判別するにはどうすればよいですか。
A.3.4. モードはデータベースまたは接続に依存していますか。
A.3.5. 厳密モードにルールを追加できますか。
A.3.6. 厳密モードはパフォーマンスに影響しますか。
A.3.7. MySQL 5.6 をインストールしたときのデフォルトのサーバー SQL モードは何ですか。

A.3.1.

サーバー SQL モードとは何ですか。

サーバー SQL モードは、MySQL でサポートされる SQL 構文、および実行されるデータ妥当性チェックの種類を定義します。これにより、MySQL をさまざまな環境で使用したり、MySQL をほかのデータベースサーバーと一緒に使用したりすることが、さらに容易になります。MySQL サーバーは、これらのモードを各クライアントに個別に適用します。詳細は、セクション5.1.7「サーバー SQL モード」を参照してください。

A.3.2.

サーバー SQL モードはいくつありますか。

各モードは、個別にオン/オフを切り替えることができます。使用可能なモードの完全なリストについては、セクション5.1.7「サーバー SQL モード」を参照してください。

A.3.3.

サーバー SQL モードを判別するにはどうすればよいですか。

--sql-mode オプションを使用すると、デフォルトの SQL モード (mysqld を起動する場合) を設定できます。SET [GLOBAL|SESSION] sql_mode='modes' ステートメントを使用すると、ローカルに接続に対して、またはグローバルに適用されるように、接続内から設定を変更できます。現在のモードを取得するには、SELECT @@sql_mode ステートメントを発行します。

A.3.4.

モードはデータベースまたは接続に依存していますか。

モードは特定のデータベースにリンクされていません。モードは、ローカルにセッション (接続) に対して設定するか、グローバルにサーバーに対して設定できます。これらの設定は、SET [GLOBAL|SESSION] sql_mode='modes' を使用して変更できます。

A.3.5.

厳密モードにルールを追加できますか。

厳密モードと呼ぶ場合は、TRADITIONALSTRICT_TRANS_TABLES、または STRICT_ALL_TABLES モードの少なくとも 1 つが有効にされているモードを意味します。オプションは組み合わせることができるため、モードに制約を追加できます。詳細は、セクション5.1.7「サーバー SQL モード」を参照してください。

A.3.6.

厳密モードはパフォーマンスに影響しますか。

一部の設定での入力データの厳密な検証では、検証を行わない場合より時間がかかります。パフォーマンスへの影響はそれほど大きくありませんが、そのような検証が必要ない場合 (アプリケーションでそのすべてをすでに処理している場合)、MySQL には厳密モードを無効にするオプションがあります。ただし、必要な場合は、厳密モードでそのような検証を行うことができます。

A.3.7.

MySQL 5.6 をインストールしたときのデフォルトのサーバー SQL モードは何ですか。

MySQL 5.6.6 の時点では、デフォルトの SQL モードは NO_ENGINE_SUBSTITUTION です。5.6.6 より前は、デフォルトのモードは空でした (どのモードも有効にされません)。使用可能なすべてのモードおよび MySQL のデフォルトの動作については、セクション5.1.7「サーバー SQL モード」を参照してください。

A.4 MySQL 5.6 FAQ: ストアドプロシージャーおよびストアドファンクション

A.4.1. MySQL 5.6 はストアドプロシージャーおよびストアドファンクションをサポートしていますか。
A.4.2. MySQL のストアドプロシージャーおよびストアドファンクションについてのドキュメントはどこにありますか。
A.4.3. MySQL のストアドプロシージャーのディスカッションフォーラムはありますか。
A.4.4. ストアドプロシージャーの ANSI SQL 2003 仕様はどこにありますか。
A.4.5. ストアドルーチンを管理するにはどうすればよいですか。
A.4.6. 特定のデータベースのすべてのストアドプロシージャーおよびストアドファンクションを表示する方法はありますか。
A.4.7. ストアドプロシージャーはどこに格納されますか。
A.4.8. ストアドプロシージャーまたはストアドファンクションをパッケージにグループ化することはできますか。
A.4.9. ストアドプロシージャーは別のストアドプロシージャーを呼び出すことができますか。
A.4.10. ストアドプロシージャーはトリガーを呼び出すことができますか。
A.4.11. ストアドプロシージャーはテーブルにアクセスできますか。
A.4.12. ストアドプロシージャーには、アプリケーションエラーを発生させるステートメントはありますか。
A.4.13. ストアドプロシージャーには例外処理はありますか。
A.4.14. MySQL 5.6 のストアドルーチンは結果セットを返すことができますか。
A.4.15. ストアドプロシージャーで WITH RECOMPILE はサポートされますか。
A.4.16. mod_plsql を Apache のゲートウェイとして使用してデータベース内のストアドプロシージャーと直接やり取りするのと同等の機能は MySQL にありますか。
A.4.17. ストアドプロシージャーに入力として配列を渡すことはできますか。
A.4.18. ストアドプロシージャーに IN パラメータとしてカーソルを渡すことはできますか。
A.4.19. ストアドプロシージャーの OUT パラメータとしてカーソルを返すことはできますか。
A.4.20. デバッグのために、ストアドルーチン内の変数の値を出力できますか。
A.4.21. ストアドプロシージャー内でトランザクションをコミットまたはロールバックできますか。
A.4.22. MySQL 5.6 のストアドプロシージャーおよびストアドファンクションはレプリケーションで動作しますか。
A.4.23. マスターサーバーで作成されたストアドプロシージャーおよびストアドファンクションはスレーブにレプリケートされますか。
A.4.24. ストアドプロシージャーおよびストアドファンクション内で実行されたアクションはどのようにレプリケートされますか。
A.4.25. レプリケーションでストアドプロシージャーおよびストアドファンクションを使用するための特別なセキュリティー要件はありますか。
A.4.26. ストアドプロシージャーおよびストアドファンクションのアクションをレプリケートする場合の制限は何ですか。
A.4.27. 前述の制限は MySQL のポイントインタイムリカバリを行う機能に影響しますか。
A.4.28. 前述の制限を修正するために何が行われていますか。

A.4.1.

MySQL 5.6 はストアドプロシージャーおよびストアドファンクションをサポートしていますか。

はい。MySQL 5.6 は 2 種類のストアドルーチン (ストアドプロシージャーおよびストアドファンクション) をサポートしています。

A.4.2.

MySQL のストアドプロシージャーおよびストアドファンクションについてのドキュメントはどこにありますか。

セクション20.2「ストアドルーチン (プロシージャーと関数) の使用」を参照してください。

A.4.3.

MySQL のストアドプロシージャーのディスカッションフォーラムはありますか。

はい。http://forums.mysql.com/list.php?98 を参照してください。

A.4.4.

ストアドプロシージャーの ANSI SQL 2003 仕様はどこにありますか。

残念ながら、正式な仕様は無料では入手できません (ANSI は有料で販売しています)。ただし、標準の包括的な概要を説明した (ストアドプロシージャーの説明を含む)、Peter Gulutzan および Trudy Pelzer 著の『SQL-99 Complete, Really』などの本があります。

A.4.5.

ストアドルーチンを管理するにはどうすればよいですか。

ストアドルーチンに明快な命名スキームを使用することはよい管理方法です。ストアドプロシージャーは、CREATE [FUNCTION|PROCEDURE]ALTER [FUNCTION|PROCEDURE]DROP [FUNCTION|PROCEDURE]、および SHOW CREATE [FUNCTION|PROCEDURE] を使用して管理できます。既存のストアドプロシージャーに関する情報を取得するには、INFORMATION_SCHEMA データベースの ROUTINES テーブル (セクション21.18「INFORMATION_SCHEMA ROUTINES テーブル」を参照してください) を使用します。

A.4.6.

特定のデータベースのすべてのストアドプロシージャーおよびストアドファンクションを表示する方法はありますか。

はい。dbname という名前のデータベースの場合、INFORMATION_SCHEMA.ROUTINES テーブルに対して次のクエリーを使用します。

SELECT ROUTINE_TYPE, ROUTINE_NAME FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA='dbname';

詳細は、セクション21.18「INFORMATION_SCHEMA ROUTINES テーブル」を参照してください。

ストアドルーチンの本体は、SHOW CREATE FUNCTION (ストアドファンクションの場合) または SHOW CREATE PROCEDURE (ストアドプロシージャーの場合) を使用して表示できます。詳細は、セクション13.7.5.11「SHOW CREATE PROCEDURE 構文」を参照してください。

A.4.7.

ストアドプロシージャーはどこに格納されますか。

mysql システムデータベースの proc テーブルに格納されます。ただし、システムデータベースのテーブルに直接アクセスしないでください。代わりに、ストアドファンクションに関する情報を取得するには SHOW CREATE FUNCTION、およびストアドプロシージャーに関する情報を取得するには SHOW CREATE PROCEDURE を使用します。これらのステートメントについては、セクション13.7.5.11「SHOW CREATE PROCEDURE 構文」を参照してください。

INFORMATION_SCHEMA データベースの ROUTINES テーブルにクエリーすることもできます。このテーブルの情報については、セクション21.18「INFORMATION_SCHEMA ROUTINES テーブル」を参照してください。

A.4.8.

ストアドプロシージャーまたはストアドファンクションをパッケージにグループ化することはできますか。

いいえ。これは MySQL 5.6 ではサポートされません。

A.4.9.

ストアドプロシージャーは別のストアドプロシージャーを呼び出すことができますか。

はい。

A.4.10.

ストアドプロシージャーはトリガーを呼び出すことができますか。

ストアドプロシージャーでは、トリガーが実行される UPDATE などの SQL ステートメントを実行できます。

A.4.11.

ストアドプロシージャーはテーブルにアクセスできますか。

はい。ストアドプロシージャーは、必要に応じて 1 つ以上のテーブルにアクセスできます。

A.4.12.

ストアドプロシージャーには、アプリケーションエラーを発生させるステートメントはありますか。

はい。MySQL 5.6 には、SQL 標準の SIGNAL ステートメントおよび RESIGNAL ステートメントが実装されています。セクション13.6.7「条件の処理」を参照してください。

A.4.13.

ストアドプロシージャーには例外処理はありますか。

MySQL には、SQL 標準に従った HANDLER 定義が実装されています。詳細は、セクション13.6.7.2「DECLARE ... HANDLER 構文」を参照してください。

A.4.14.

MySQL 5.6 のストアドルーチンは結果セットを返すことができますか。

ストアドプロシージャーは返すことができますが、ストアドファンクションは返すことができません。ストアドプロシージャー内で通常の SELECT を実行すると、結果セットがクライアントに直接返されます。これが動作するようにするには、MySQL 4.1 (以降) のクライアント/サーバープロトコルを使用する必要があります。これは、たとえば PHP では、古い mysql 拡張ではなく mysqli 拡張を使用する必要があることを意味します。

A.4.15.

ストアドプロシージャーで WITH RECOMPILE はサポートされますか。

MySQL 5.6 にはありません。

A.4.16.

mod_plsql を Apache のゲートウェイとして使用してデータベース内のストアドプロシージャーと直接やり取りするのと同等の機能は MySQL にありますか。

MySQL 5.6 には同等の機能はありません。

A.4.17.

ストアドプロシージャーに入力として配列を渡すことはできますか。

MySQL 5.6 にはありません。

A.4.18.

ストアドプロシージャーに IN パラメータとしてカーソルを渡すことはできますか。

MySQL 5.6 では、カーソルはストアドプロシージャーの内部でのみ使用できます。

A.4.19.

ストアドプロシージャーの OUT パラメータとしてカーソルを返すことはできますか。

MySQL 5.6 では、カーソルはストアドプロシージャーの内部でのみ使用できます。ただし、SELECT でカーソルを開かない場合、結果はクライアントに直接送信されます。変数に対して SELECT INTO を発行することもできます。セクション13.2.9「SELECT 構文」を参照してください。

A.4.20.

デバッグのために、ストアドルーチン内の変数の値を出力できますか。

はい。これは、ストアドプロシージャーでは行うことができますが、ストアドファンクションでは行うことはできません。ストアドプロシージャー内で通常の SELECT を実行すると、結果セットがクライアントに直接返されます。これが動作するようにするには、MySQL 4.1 (以降) のクライアント/サーバープロトコルを使用する必要があります。これは、たとえば PHP では、古い mysql 拡張ではなく mysqli 拡張を使用する必要があることを意味します。

A.4.21.

ストアドプロシージャー内でトランザクションをコミットまたはロールバックできますか。

はい。ただし、ストアドファンクション内でトランザクション操作を実行することはできません。

A.4.22.

MySQL 5.6 のストアドプロシージャーおよびストアドファンクションはレプリケーションで動作しますか。

はい。ストアドプロシージャーおよびストアドファンクションで実行された通常のアクションは、マスター MySQL サーバーからスレーブサーバーにレプリケートされます。セクション20.7「ストアドプログラムのバイナリロギング」で詳しく説明されているいくつかの制限があります。

A.4.23.

マスターサーバーで作成されたストアドプロシージャーおよびストアドファンクションはスレーブにレプリケートされますか。

はい。マスターサーバーで通常の DDL ステートメントを使用して実行されたストアドプロシージャーおよびストアドファンクションの作成はスレーブにレプリケートされるため、オブジェクトは両方のサーバーに存在します。ストアドプロシージャーおよびストアドファンクションに対する ALTER ステートメントおよび DROP ステートメントもレプリケートされます。

A.4.24.

ストアドプロシージャーおよびストアドファンクション内で実行されたアクションはどのようにレプリケートされますか。

MySQL は、ストアドプロシージャーで行われた各 DML イベントを記録し、それらの個々のアクションをスレーブサーバーにレプリケートします。ストアドプロシージャーを実行するために行われた実際の呼び出しはレプリケートされません。

データを変更するストアドファンクションは、各ファンクション内で行われた DML イベントとしてではなく、関数呼び出しとしてログ記録されます。

A.4.25.

レプリケーションでストアドプロシージャーおよびストアドファンクションを使用するための特別なセキュリティー要件はありますか。

はい。スレーブサーバーにはマスターのバイナリログから読み取ったステートメントを実行する権限があるため、レプリケーションでストアドファンクションを使用するための特殊なセキュリティー制約が存在します。レプリケーションまたは一般のバイナリロギング (ポイントインタイムリカバリのための) がアクティブである場合、MySQL の DBA には選択できるセキュリティーオプションが 2 つあります。

  1. ストアドファンクションを作成するユーザーに、SUPER 権限を付与する必要があります。

  2. または、DBA は log_bin_trust_function_creators システム変数に 1 を設定できます。これにより、標準の CREATE ROUTINE 権限を持ったユーザーがストアドファンクションを作成できます。

A.4.26.

ストアドプロシージャーおよびストアドファンクションのアクションをレプリケートする場合の制限は何ですか。

ストアドプロシージャーに埋め込まれている決定性のない (ランダムな) アクションまたは時間ベースのアクションは、正しくレプリケートされないことがあります。その特性により、ランダムに生成された結果は予測できず、正確に再現できません。このため、スレーブにレプリケートされたランダムアクションは、マスターで実行されたアクションとは異なります。ストアドファンクションを DETERMINISTIC として宣言した場合、または log_bin_trust_function_creators システム変数に 0 を設定した場合は、ランダムに値が設定される操作を呼び出すことはできません。

また、時間ベースのアクションはスレーブで再現できません。ストアドプロシージャーのそのようなアクションのタイミングは、レプリケーションに使用されるバイナリログを介して再現できないためです。バイナリログには、DML イベントのみが記録され、タイミング制約は含まれていません。

最後に、非トランザクションテーブルで大きい DML アクション (一括挿入など) 中にエラーが発生した場合、マスターは DML アクティビティーによって部分的に更新されたがスレーブが更新されず、レプリケーションの問題が発生することがあります。回避策は、関数の DML アクションを IGNORE キーワードを指定して実行することであり、マスターでエラーが発生した更新が無視され、エラーが発生しなかった更新がスレーブにレプリケートされるようにします。

A.4.27.

前述の制限は MySQL のポイントインタイムリカバリを行う機能に影響しますか。

レプリケーションに影響する制限が、ポイントインタイムリカバリに同様に影響します。

A.4.28.

前述の制限を修正するために何が行われていますか。

ステートメントベースのレプリケーションまたは行ベースのレプリケーションのいずれかを選択できます。元のレプリケーションの実装は、ステートメントベースのバイナリロギングに基づいています。行ベースのバイナリロギングによって、前述の制限が解決されます。

複合レプリケーションも使用できます (--binlog-format=mixed を指定してサーバーを起動します)。このハイブリッドの賢い形式のレプリケーションは、ステートメントレベルのレプリケーションを安全に使用できるかどうか、または行レベルのレプリケーションが必要であるかを判断します。

追加情報については、セクション17.1.2「レプリケーション形式」を参照してください。

A.5 MySQL 5.6 FAQ: トリガー

A.5.1. MySQL 5.6 のトリガーについてのドキュメントはどこにありますか。
A.5.2. MySQL のトリガーについてのディスカッションフォーラムはありますか。
A.5.3. MySQL 5.6 にはステートメントレベルまたは行レベルのトリガーはありますか。
A.5.4. デフォルトのトリガーはありますか。
A.5.5. MySQL でトリガーを管理するにはどうすればよいですか。
A.5.6. 特定のデータベースのすべてのトリガーを表示する方法はありますか。
A.5.7. トリガーはどこに格納されますか。
A.5.8. トリガーはストアドプロシージャーを呼び出すことができますか。
A.5.9. トリガーはテーブルにアクセスできますか。
A.5.10. 1 つのテーブルに同じトリガーイベントおよびアクション時間のトリガーを複数定義することはできますか。
A.5.11. トリガーでは UDF を使用して外部アプリケーションを呼び出すことができますか。
A.5.12. トリガーはリモートサーバー上のテーブルを更新できますか。
A.5.13. トリガーはレプリケーションで動作しますか。
A.5.14. マスターでトリガーによって実行されたアクションはどのようにスレーブにレプリケートされますか。

A.5.1.

MySQL 5.6 のトリガーについてのドキュメントはどこにありますか。

セクション20.3「トリガーの使用」を参照してください。

A.5.2.

MySQL のトリガーについてのディスカッションフォーラムはありますか。

はい。http://forums.mysql.com/list.php?99 にあります。

A.5.3.

MySQL 5.6 にはステートメントレベルまたは行レベルのトリガーはありますか。

MySQL 5.6 では、すべてのトリガーは FOR EACH ROW です。つまり、挿入、更新、または削除される各行に対してトリガーが実行されます。MySQL 5.6 は FOR EACH STATEMENT を使用したトリガーをサポートしていません。

A.5.4.

デフォルトのトリガーはありますか。

明示的にはありません。MySQL は、一部の TIMESTAMP カラム、および AUTO_INCREMENT を使用して定義されたカラムに特殊な動作を割り当てています。

A.5.5.

MySQL でトリガーを管理するにはどうすればよいですか。

MySQL 5.6 では、トリガーを作成する場合は CREATE TRIGGER ステートメントを使用し、削除する場合は DROP TRIGGER を使用します。これらのステートメントについては、セクション13.1.19「CREATE TRIGGER 構文」およびセクション13.1.30「DROP TRIGGER 構文」を参照してください。

トリガーに関する情報は、INFORMATION_SCHEMA.TRIGGERS テーブルをクエリーすることによって取得できます。セクション21.26「INFORMATION_SCHEMA TRIGGERS テーブル」を参照してください。

A.5.6.

特定のデータベースのすべてのトリガーを表示する方法はありますか。

はい。データベース dbname に定義されているすべてのトリガーのリストを取得するには、INFORMATION_SCHEMA.TRIGGERS テーブルに対して次のようなクエリーを使用します。

SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_STATEMENT FROM INFORMATION_SCHEMA.TRIGGERS WHERE TRIGGER_SCHEMA='dbname';

このテーブルについては、セクション21.26「INFORMATION_SCHEMA TRIGGERS テーブル」を参照してください。

MySQL に固有の SHOW TRIGGERS ステートメントを使用することもできます。セクション13.7.5.39「SHOW TRIGGERS 構文」を参照してください。

A.5.7.

トリガーはどこに格納されますか。

テーブルのトリガーは、現在、.TRG ファイルに格納され、テーブルごとにそのようなファイルが 1 つあります。

A.5.8.

トリガーはストアドプロシージャーを呼び出すことができますか。

はい。

A.5.9.

トリガーはテーブルにアクセスできますか。

トリガーは、それ自体が定義されているテーブルの古いデータおよび新しいデータの両方にアクセスできます。トリガーはほかのテーブルに影響を与えることもできますが、その関数またはトリガーを呼び出したステートメントによってすでに使用されている (読み取りまたは書き込みのために) テーブルを変更することはできません。

A.5.10.

1 つのテーブルに同じトリガーイベントおよびアクション時間のトリガーを複数定義することはできますか。

MySQL 5.6 では、同じトリガーイベントおよびアクション時間を持つ複数のトリガーを特定のテーブルに定義することはできません。たとえば、1 つのテーブルに対して 2 つの BEFORE UPDATE トリガーを定義することはできません。この制限は MySQL 5.7 で解除されました。

A.5.11.

トリガーでは UDF を使用して外部アプリケーションを呼び出すことができますか。

はい。たとえば、トリガーは sys_exec() という UDF を呼び出すことができます。

A.5.12.

トリガーはリモートサーバー上のテーブルを更新できますか。

はい。リモートサーバー上のテーブルは、FEDERATED ストレージエンジンを使用して更新できます。(セクション15.8「FEDERATED ストレージエンジン」を参照してください)。

A.5.13.

トリガーはレプリケーションで動作しますか。

はい。ただし、それらが動作する仕組みは、MySQL のすべてのバージョンで使用できる標準のステートメントベースのレプリケーション、または MySQL 5.1 で導入された行ベースのレプリケーション形式のいずれを使用しているかによって異なります。

ステートメントベースのレプリケーションを使用している場合、スレーブのトリガーは、マスターで実行されてスレーブにレプリケートされたステートメントによって実行されます。

行ベースのレプリケーションを使用している場合、スレーブのトリガーは、マスターで実行されてスレーブにレプリケートされたステートメントによって実行されません。代わりに、行ベースのレプリケーションを使用した場合は、マスターでトリガーが実行されたことによる変更がスレーブに適用されます。

詳細は、セクション17.4.1.32「レプリケーションとトリガー」を参照してください。

A.5.14.

マスターでトリガーによって実行されたアクションはどのようにスレーブにレプリケートされますか。

これは、ステートメントベースのレプリケーションまたは行ベースのレプリケーションのいずれを使用しているかによって異なります。

ステートメントベースのレプリケーション  まず、マスターに存在するトリガーをスレーブサーバーに再作成する必要があります。これが行われると、レプリケーションに関与するほかの標準の DML ステートメントと同様に、レプリケーションフローが動作します。たとえば、マスター MySQL サーバーに存在する、AFTER 挿入トリガーを持つテーブル EMP について考えてみましょう。同じ EMP テーブルおよび AFTER 挿入トリガーが、スレーブサーバーにも存在します。レプリケーションフローは次のようになります。

  1. INSERT ステートメントが EMP に発行されます。

  2. EMPAFTER トリガーが実行されます。

  3. INSERT ステートメントがバイナリログに書き込まれます。

  4. レプリケーションのスレーブは、EMP に対するその INSERT ステートメントを取得してそれを実行します。

  5. スレーブに存在する EMPAFTER トリガーが実行されます。

行ベースのレプリケーション  行ベースのレプリケーションを使用している場合は、マスターでトリガーが実行されたことによる変更がスレーブに適用されます。ただし、行ベースのレプリケーションでは、トリガー自体は実際にはスレーブで実行されません。これは、マスターとスレーブの両方にマスターの変更が適用され、さらにそれらの変更を行なったトリガーがスレーブで実行された場合、その変更は実際には 2 回スレーブに適用され、マスターとスレーブのデータが異なるデータとなってしまうためです。

ほとんどの場合、行ベースのレプリケーションおよびステートメントベースのレプリケーションで結果は同じです。ただし、マスターとスレーブで異なるトリガーを使用している場合、行ベースのレプリケーションは使用できません。(これは、行ベース形式は、トリガーが実行されるきっかけとなったステートメントではなく、マスターで実行されたトリガーによる変更をスレーブにレプリケートし、スレーブの対応するトリガーは実行されないためです。)代わりに、そのようなトリガーが実行されるきっかけとなったステートメントを、ステートメントベースのレプリケーションを使用してレプリケートする必要があります。

詳細は、セクション17.4.1.32「レプリケーションとトリガー」を参照してください。

A.6 MySQL 5.6 FAQ: ビュー

A.6.1. MySQL のビューについて説明しているドキュメントはどこにありますか。
A.6.2. MySQL のビューについてのディスカッションフォーラムはありますか。
A.6.3. 基礎テーブルが削除または名前変更された場合、ビューはどうなりますか。
A.6.4. MySQL 5.6 にはテーブルのスナップショットはありますか。
A.6.5. MySQL 5.6 にはマテリアライズドビューはありますか。
A.6.6. 結合に基づいているビューに挿入できますか。

A.6.1.

MySQL のビューについて説明しているドキュメントはどこにありますか。

セクション20.5「ビューの使用」を参照してください。

A.6.2.

MySQL のビューについてのディスカッションフォーラムはありますか。

はい。http://forums.mysql.com/list.php?100 を参照してください。

A.6.3.

基礎テーブルが削除または名前変更された場合、ビューはどうなりますか。

ビューが作成されたあとに、その定義が参照しているテーブルまたはビューを削除または変更できます。この種類の問題に関してビュー定義を確認するには、CHECK TABLE ステートメントを使用します。(セクション13.7.2.2「CHECK TABLE 構文」を参照してください。)

A.6.4.

MySQL 5.6 にはテーブルのスナップショットはありますか。

いいえ。

A.6.5.

MySQL 5.6 にはマテリアライズドビューはありますか。

いいえ。

A.6.6.

結合に基づいているビューに挿入できますか。

INSERT ステートメントに、関連するテーブルが 1 つのみであることを明確にするカラムリストがある場合は、実行できます。

ビューに対する単一の挿入で、複数のテーブルに挿入することはできません

A.7 MySQL 5.6 FAQ: INFORMATION_SCHEMA

A.7.1. MySQL の INFORMATION_SCHEMA データベースについてのドキュメントはどこにありますか。
A.7.2. INFORMATION_SCHEMA についてのディスカッションフォーラムはありますか。
A.7.3. INFORMATION_SCHEMA の ANSI SQL 2003 仕様はどこにありますか。
A.7.4. Oracle のデータディクショナリと MySQL の INFORMATION_SCHEMA の違いは何ですか。
A.7.5. INFORMATION_SCHEMA データベースのテーブルに挿入または変更を行うことはできますか。

A.7.1.

MySQL の INFORMATION_SCHEMA データベースについてのドキュメントはどこにありますか。

第21章「INFORMATION_SCHEMA テーブルを参照してください。

A.7.2.

INFORMATION_SCHEMA についてのディスカッションフォーラムはありますか。

http://forums.mysql.com/list.php?101 を参照してください。

A.7.3.

INFORMATION_SCHEMA の ANSI SQL 2003 仕様はどこにありますか。

残念ながら、正式な仕様は無料では入手できません。(ANSI は有料で販売しています。)ただし、標準の包括的な概要を説明した (INFORMATION_SCHEMA を含む)、Peter Gulutzan および Trudy Pelzer 著の『SQL-99 Complete, Really』などの本があります。

A.7.4.

Oracle のデータディクショナリと MySQL の INFORMATION_SCHEMA の違いは何ですか。

Oracle および MySQL は両方とも、テーブルにメタデータを提供しています。ただし、Oracle と MySQL では異なるテーブル名およびカラム名が使用されています。MySQL の実装は、SQL 標準に定義されている INFORMATION_SCHEMA をサポートしている DB2 および SQL Server により似ています。

A.7.5.

INFORMATION_SCHEMA データベースのテーブルに挿入または変更を行うことはできますか。

いいえ。アプリケーションが特定の標準構造に依存していることがあるため、変更しないでください。このため、INFORMATION_SCHEMA テーブルまたはデータを変更したことによるバグまたはその他の問題はサポートできません

A.8 MySQL 5.6 FAQ: 移行

A.8.1. MySQL 5.5 から MySQL 5.6 に移行する方法に関する情報はどこにありますか。
A.8.2. MySQL 5.6 のストレージエンジン (テーブルタイプ) のサポートは、以前のバージョンからどのように変更されましたか。

A.8.1.

MySQL 5.5 から MySQL 5.6 に移行する方法に関する情報はどこにありますか。

アップグレード情報については、セクション2.11.1「MySQL のアップグレード」を参照してください。アップグレード時はメジャーバージョンをスキップせずに、各手順でメジャーバージョンから次のメジャーバージョンにアップグレードして、手順の操作を完了してください。これはより複雑に見えますが、時間を節約してトラブルを避けることができます。アップグレード中に問題が発生した場合に、ユーザー自身または (MySQL Enterprise サブスクリプションがある場合は) MySQL サポートがその原因を識別しやすくなります。

A.8.2.

MySQL 5.6 のストレージエンジン (テーブルタイプ) のサポートは、以前のバージョンからどのように変更されましたか。

ストレージエンジンのサポートは次のように変更されました。

  • ISAM テーブルのサポートは MySQL 5.0 で削除されたため、ISAM の代わりに MyISAM ストレージエンジンを使用してください。テーブル tblnameISAM から MyISAM に変更するには、次のようなステートメントを発行します。

    ALTER TABLE tblname ENGINE=MYISAM;
  • MyISAM テーブルの内部 RAID も MySQL 5.0 で削除されました。これは、2G バイトを超えるファイルサイズをサポートしていないファイルシステムで大きいテーブルを許容するために以前使用されていました。現在のすべてのファイルシステムではより大きいテーブルが許容されます。MERGE テーブル、ビューなどの新しいほかのソリューションもあります。

  • すべてのストレージエンジンの VARCHAR カラム型で、末尾のスペースが維持されるようになりました。

  • MEMORY テーブル (以前は HEAP テーブルと呼ばれました) にも VARCHAR カラムを含めることができます。

A.9 MySQL 5.6 FAQ: セキュリティー

A.9.1. MySQL のセキュリティーの問題に関するドキュメントはどこにありますか。
A.9.2. MySQL 5.6 には SSL に対するネイティブなサポートはありますか。
A.9.3. SSL のサポートは MySQL バイナリに組み込まれていますか。それとも、バイナリを再コンパイルして有効にする必要がありますか。
A.9.4. MySQL 5.6 には LDAP ディレクトリに対する組み込みの認証はありますか。
A.9.5. MySQL 5.6 にはロールベースのアクセス制御 (RBAC) のサポートは含まれていますか。

A.9.1.

MySQL のセキュリティーの問題に関するドキュメントはどこにありますか。

最初に第6章「セキュリティーをお読みください。

特定のセキュリティーの問題に関して役に立つことがある MySQL ドキュメントのほかの部分としては、次のセクションがあります。

A.9.2.

MySQL 5.6 には SSL に対するネイティブなサポートはありますか。

ほとんどの 5.6 バイナリには、クライアントおよびサーバー間の SSL 接続のサポートがあります。セクション6.3.10「セキュアな接続のための SSL の使用」を参照してください。

(たとえば) クライアントアプリケーションで SSL 接続がサポートされない場合は、SSH を使用して接続をトンネルすることもできます。例については、セクション6.3.11「SSH を使用した Windows から MySQL へのリモート接続」を参照してください。

A.9.3.

SSL のサポートは MySQL バイナリに組み込まれていますか。それとも、バイナリを再コンパイルして有効にする必要がありますか。

ほとんどの 5.6 バイナリでは、セキュアなクライアントとサーバーの接続、認証が行われるクライアントとサーバーの接続、またはその両方に対して SSL が有効にされます。セクション6.3.10「セキュアな接続のための SSL の使用」を参照してください。

A.9.4.

MySQL 5.6 には LDAP ディレクトリに対する組み込みの認証はありますか。

現在はありません。

A.9.5.

MySQL 5.6 にはロールベースのアクセス制御 (RBAC) のサポートは含まれていますか。

現在はありません。

A.10 MySQL 5.6 FAQ: MySQL Cluster

次のセクションでは、MySQL Cluster および NDB ストレージエンジンに関するよくある質問に回答します。

A.10.1. クラスタがサポートされる MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。
A.10.2. 「NDB」 および 「NDBCLUSTER」 は何を意味していますか。
A.10.3. MySQL Cluster を使用した場合と MySQL Replication を使用した場合の違いは何ですか。
A.10.4. MySQL Cluster を実行するには、特殊なネットワーク環境が必要となりますか。クラスタ内のコンピュータはどのように通信しますか。
A.10.5. MySQL Cluster を実行するために必要なコンピュータは何台ですか。その理由は何ですか。
A.10.6. MySQL Cluster 内の各種のコンピュータにはどのような役割がありますか。
A.10.7. MySQL Cluster の管理クライアントで SHOW コマンドを実行すると、次のような出力行が表示されます。
A.10.8. MySQL Cluster を使用できるオペレーティングシステムはどれですか。
A.10.9. MySQL Cluster を実行するためのハードウェア要件は何ですか。
A.10.10. MySQL Cluster を使用するために必要な RAM のサイズはどれくらいですか。ディスクメモリーを使用することはできますか。
A.10.11. MySQL Cluster に使用できるファイルシステムは何ですか。ネットワークファイルシステムまたはネットワーク共有は使用できますか。
A.10.12. MySQL Cluster のノードは、仮想マシン (VMWare、Parallels、Xen によって作成された仮想マシンなど) 内で実行できますか。
A.10.13. MySQL Cluster データベースにデータを移入しようとしています。ロード処理が予期せずに終了し、次のようなエラーメッセージが表示されます。
A.10.14. MySQL Cluster は TCP/IP を使用しています。これは、1 つ以上のノードをリモートの場所に配置して、インターネット経由で実行できることを意味しますか。
A.10.15. MySQL Cluster を使用するために、新しいプログラミング言語またはクエリー言語を学習する必要がありますか。
A.10.16. MySQL Cluster によってサポートされるプログラミング言語および API は何ですか。
A.10.17. MySQL Cluster には管理ツールが含まれていますか。
A.10.18. MySQL Cluster を使用しているときに、エラーメッセージまたは警告メッセージの意味を確認するにはどうすればよいですか。
A.10.19. MySQL Cluster はトランザクションセーフですか。どのような分離レベルがサポートされますか。
A.10.20. MySQL Cluster によってサポートされるストレージエンジンは何ですか。
A.10.21. 壊滅的な障害が発生した場合 (たとえば、街全体が停電かつUPS の障害が発生した場合)、すべてのデータが失われますか。
A.10.22. MySQL Cluster では FULLTEXT インデックスを使用できますか。
A.10.23. 単一のコンピュータ上で複数のノードを実行できますか。
A.10.24. MySQL Cluster を再起動せずにデータノードを追加できますか。
A.10.25. MySQL Cluster を使用するときに、注意するべき制限はありますか。
A.10.26. MySQL Cluster では外部キーはサポートされますか。
A.10.27. 既存の MySQL データベースを MySQL Cluster にインポートするにはどうすればよいですか。
A.10.28. MySQL Cluster のノードはどのようにして相互にやり取りしますか。
A.10.29. アービトレータとは何ですか。
A.10.30. MySQL Cluster によってサポートされるデータ型を何ですか。
A.10.31. MySQL Cluster を起動および停止するにはどうすればよいですか。
A.10.32. MySQL Cluster をシャットダウンすると、MySQL Cluster のデータはどうなりますか。
A.10.33. MySQL Cluster に複数の管理ノードを使用することはよい考えですか。
A.10.34. 単一の MySQL Cluster に、異なる種類のハードウェアおよびオペレーティングシステムを混在させることはできますか。
A.10.35. 単一のホスト上で 2 つのデータノードを実行できますか。2 つの SQL ノードは実行できますか。
A.10.36. MySQL Cluster ではホスト名を使用できますか。
A.10.37. MySQL Cluster では IPv6 はサポートされますか。
A.10.38. 複数の MySQL サーバーを持つ MySQL Cluster で MySQL ユーザーを管理するにはどうすればよいですか。
A.10.39. SQL ノードの 1 つで障害が発生した場合に、クエリーの送信を続けるにはどうすればよいですか。
A.10.40. MySQL Cluster をバックアップおよびリストアするにはどうすればよいですか。
A.10.41. 「エンジェルプロセス」とは何ですか。

A.10.1.

クラスタがサポートされる MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。

MySQL Cluster は標準の MySQL Server 5.6 リリースではサポートされません。そうではなく、MySQL Cluster は個別の製品として提供されています。現在、次の MySQL Cluster リリースを本番で使用できます。

  • MySQL Cluster NDB 7.1  このシリーズは MySQL Cluster の以前の一般提供 (GA) バージョンであり、引き続き本番に使用できますが、新しい配備では MySQL Cluster NDB 7.3 を使用することをお勧めします。最新の MySQL Cluster NDB 7.1 リリースは http://dev.mysql.com/downloads/cluster/ から入手できます。

  • MySQL Cluster NDB 7.2  このシリーズは MySQL Cluster の一般提供 (GA) バージョンであり、引き続き本番に使用できますが、新しい配備では最新の MySQL Cluster NDB 7.3 リリースを使用することをお勧めします。最新の MySQL Cluster NDB 7.2 リリースは http://dev.mysql.com/downloads/cluster/ から入手できます。

  • MySQL Cluster NDB 7.3  このシリーズは、MySQL Cluster の最新の一般提供 (GA) バージョンであり、NDB ストレージエンジンのバージョン 7.3 および MySQL Server 5.6 に基づいています。新しい配備には、このシリーズの最新のリリースを使用してください。最新の MySQL Cluster NDB 7.3 リリースは http://dev.mysql.com/downloads/cluster/ から入手できます。

  • MySQL Cluster NDB 7.4  これは、MySQL Cluster の現在の開発バージョンであり、NDB ストレージエンジンのバージョン 7.4 および MySQL Server 5.6 に基づいています。現在、MySQL Cluster NDB 7.4 はテストおよび評価のために使用できます。最新の MySQL Cluster NDB 7.4 リリースは http://dev.mysql.com/downloads/cluster/ から入手できます。

    MySQL Cluster NDB 7.4 での改善点の概要については、セクション18.1.4.2「MySQL Cluster NDB 7.4 での MySQL Cluster の開発」を参照してください。

新しい配備には、MySQL Cluster NDB 7.2 または MySQL Cluster NDB 7.3 を使用してください。古いバージョンの MySQL Cluster を使用している場合は、これらのいずれかにできるかぎり早くアップグレードしてください。MySQL Cluster NDB 7.2 での改善点の概要については、What is New in MySQL NDB Cluster 7.2を参照してください。MySQL Cluster NDB 7.3 での改善点については、セクション18.1.4.1「MySQL Cluster NDB 7.3 での MySQL Cluster の開発」を参照してください。

使用している MySQL Server で NDB がサポートされるかどうかを判別するには、SHOW VARIABLES LIKE 'have_%'SHOW ENGINES、または SHOW PLUGINS ステートメントのいずれかを使用します。

A.10.2.

NDB および NDBCLUSTER は何を意味していますか。

NDBNetwork Database を意味しています。NDB および NDBCLUSTER は、MySQL でクラスタがサポートされるストレージエンジンの名前です。開発者は NDB を好んでいますが、どちらの名前も正しい名前です。両方の名前がドキュメントに記述され、どちらの名前も MySQL Cluster テーブルを作成するための CREATE TABLE ステートメントの ENGINE オプションに使用できます。

A.10.3.

MySQL Cluster を使用した場合と MySQL Replication を使用した場合の違いは何ですか。

従来の MySQL レプリケーションでは、マスター MySQL サーバーが 1 つ以上のスレーブを更新します。トランザクションは順次的にコミットされ、遅いトランザクションの場合、スレーブでの処理がマスターより遅れることがあります。これは、マスターで障害が発生した場合に、スレーブで最後のいくつかのトランザクションが記録されないことがあることを意味します。InnoDB などのトランザクションセーフなエンジンを使用している場合、トランザクションはスレーブで完了するかまったく適用されないかのいずれかであり、レプリケーションではマスターおよびスレーブのすべてのデータが常時整合性がとれていることは保証されません。MySQL Cluster では、すべてのデータノードの同期が維持され、あるデータノードでコミットされたトランザクションはすべてのデータノードでコミットされます。データノードの障害が発生した場合、ほかのすべてのデータノードでは整合性のある状態が維持されます。

簡単に言うと、標準の MySQL レプリケーションは非同期で実行され、MySQL Cluster は同期を維持して実行されます。

非同期レプリケーションは MySQL Cluster でも使用できます。MySQL Cluster Replication (ジオレプリケーションを呼ばれることもあります) には、2 つの MySQL Cluster 間のレプリケーション、および MySQL Cluster からクラスタ化されていない MySQL サーバーへのレプリケーションの両方を行う機能が含まれています。セクション18.6「MySQL Cluster レプリケーション」を参照してください。

A.10.4.

MySQL Cluster を実行するには、特殊なネットワーク環境が必要となりますか。クラスタ内のコンピュータはどのように通信しますか。

MySQL Cluster は、TCP/IP を使用してコンピュータが接続されている高帯域幅の環境で使用することが意図されています。そのパフォーマンスは、クラスタ内のコンピュータ間の接続速度に直接関係しています。MySQL Cluster の最低限の接続要件には、一般的な 100 メガビット Ethernet ネットワークまたは同等のものが含まれます。可能な場合はギガビット Ethernet を使用することをお勧めします。

より速い SCI プロトコルもサポートされますが、特殊なハードウェアが必要となります。SCI については、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。

A.10.5.

MySQL Cluster を実行するために必要なコンピュータは何台ですか。その理由は何ですか。

実行可能なクラスタの実行には、少なくとも 3 台のコンピュータが必要となります。ただし、MySQL Cluster の推奨される最低限のコンピュータの数は 4 台であり、管理ノードと SQL ノードを実行するためにそれぞれ 1 台ずつ、およびデータノードとして使用される 2 台のコンピュータです。データノードを 2 台にする目的は冗長性を持たせるためです。管理ノードは別個のマシンで実行して、いずれかのデータノードで障害が発生した場合にアービトレーションサービスが継続されることを保証する必要があります。

スループットおよび高可用性を向上させるには、複数の SQL ノード (クラスタに接続された MySQL サーバー) を使用してください。複数の管理サーバーを実行することもできます (必須ではありません)。

A.10.6.

MySQL Cluster 内の各種のコンピュータにはどのような役割がありますか。

MySQL Cluster には、コンピュータを物理的要素とする、物理組織および論理組織の両方があります。クラスタの論理要素または機能要素はノードと呼ばれ、クラスタのノードを収容するコンピュータはクラスタホストと呼ばれることがあります。クラスタ内の特定のロールにそれぞれ対応する 3 つのタイプのノードがあります。これらを次に示します。

  • 管理ノード  このノードはクラスタ全体の管理サービス (起動、シャットダウン、バックアップ、およびほかのノードの構成データを含む) を提供します。管理ノードサーバーはアプリケーション ndb_mgmd として実装されます。MySQL Cluster を制御するために使用される管理クライアントは ndb_mgm です。これらのプログラムについては、セクション18.4.4「ndb_mgmd — MySQL Cluster 管理サーバーデーモン」およびセクション18.4.5「ndb_mgm — MySQL Cluster 管理クライアント」を参照してください。

  • データノード  このタイプのノードは、データを格納およびレプリケートします。データノードの機能は、NDB データノードプロセスndbd のインスタンスによって処理されます。詳細は、セクション18.4.1「ndbd — MySQL Cluster データノードデーモン」を参照してください。

  • SQL ノード  これは、単純に MySQL サーバーのインスタンス (mysqld) であり、NDBCLUSTER ストレージエンジンのサポートを組み込んでビルドされていて、--ndb-cluster オプションを指定して起動することによってこのエンジンを有効にし、--ndb-connectstring オプションを指定して MySQL Cluster の管理サーバーに接続できるようにします。これらのオプションについては、セクション18.3.4.2「MySQL Cluster 用の MySQL Server オプション」を参照してください。

    注記

    API ノードは、データの格納および取得のためにクラスタのデータノードを直接使用するアプリケーションです。このため、SQL ノードは MySQL サーバーを使用してクラスタへの SQL インタフェースを提供する API ノードの一種であると考えることができます。直接的でオブジェクト指向のトランザクションおよび MySQL Cluster のデータへのスキャンインタフェースを提供するそのようなアプリケーション (MySQL サーバーに依存しない) は、NDB API を使用して記述できます。詳細は、NDB Cluster API Overview: The NDB APIを参照してください。

A.10.7.

MySQL Cluster の管理クライアントで SHOW コマンドを実行すると、次のような出力行が表示されます。

id=2 @10.100.10.32 (Version: 5.6.22-ndb-7.3.9 Nodegroup: 0, *)

「*」は何を意味していますか。このノードはほかのノードとどのように異なりますか。

もっとも簡単な回答は、ユーザーが制御できるものではなく、MySQL Cluster のソースコードを記述または分析するソフトウェアエンジニアではないかぎり、どのような場合でも憂慮する必要はないものですとなります。

この回答に満足できない場合、より長くテクニカルなバージョンは次のとおりです。

MySQL Cluster の多数のメカニズムでは、データノードの分散調整が必要となります。これらの分散アルゴリズムおよびプロトコルには、グローバルチェックポイント、DDL (スキーマ) の変更、およびノードの再起動処理が含まれます。この調整を単純にするために、それらのメンバーのいずれかがリーダーとして動作するようにデータノードで選出されます。(このノードはマスターと呼ばれていましたが、MySQL Replication のマスターサーバーと混乱しないように、この用語は削除されました。)この選択は完全に自動的であり、それに影響するメカニズムをユーザーが目にすることはありません。自動的であることが、MySQL Cluster の内部アーキテクチャーの重要な部分です。

ノードがこれらのメカニズムのリーダーとして動作する場合、通常、それがアクティビティーの調整の中心となり、フォロワーとして動作するほかのノードは、リーダーによって指示されたアクティビティーの各自の担当分を実行します。リーダーとして動作するノードで障害が発生すると、残りのノードによって新しいリーダーが選出されます。古いリーダーによって調整されていた進行中のタスクは、実際に関係するメカニズムに従って、失敗するか、新しいリーダーによって続行されます。

これらの各種のメカニズムおよびプロトコルの一部で別のリーダーノードが使用されることがありますが、一般的には、それらのすべてで同じリーダーが選択されます。管理クライアントの SHOW の出力でリーダーとして示されるノードは、DDL およびメタデータのアクティビティーの調整を担当する DICT マネージャーと内部では呼ばれています (詳細は、『MySQL Cluster API Developer Guide』のThe DBDICT Blockを参照してください)。

MySQL Cluster は、リーダーの選択がクラスタの外部で認識できるような影響を及ぼさないように設計されています。たとえば、現在のリーダーの CPU またはリソースの使用量がほかのデータノードより著しく高いことはなく、リーダーで障害が発生した場合にほかのデータノードで障害が発生した場合よりクラスタに対して特別に大きい影響があるということはありません。

A.10.8.

MySQL Cluster を使用できるオペレーティングシステムはどれですか。

MySQL Cluster はほとんどの Unix 系のオペレーティングシステムでサポートされています。MySQL Cluster NDB 7.2 は、Microsoft Windows オペレーティングシステムの本番設定でもサポートされます。

さまざまなオペレーティングシステムのバージョン、オペレーティングシステムの配布、およびハードウェアプラットフォームで MySQL Cluster に提供されるサポートのレベルについては、http://www.mysql.com/support/supportedplatforms/cluster.htmlを参照してください。

A.10.9.

MySQL Cluster を実行するためのハードウェア要件は何ですか。

MySQL Cluster は NDB 対応のバイナリを使用できるプラットフォームで実行してください。データノードおよび API ノードの場合、より速い CPU およびより多くのメモリーによって、パフォーマンスが向上することがあり、64 ビットの CPU は 32 ビットのプロセッサよりも効率的である場合があります。各ノードのデータベースの分担を保持するために、データノードに使用されるマシンに十分なメモリーがある必要があります (詳細は、「必要な RAM のサイズはどれくらいですか」を参照してください)。MySQL Cluster の管理サーバーを実行するためにのみ使用されるコンピュータの場合、要件は最低限のものです。通常、このタスクには一般的なデスクトップ PC (または同等のもの) で十分です。ノードは標準の TCP/IP ネットワークおよびハードウェアを使用して通信できます。高速の SCI プロトコルを使用することもできます。ただし、SCI を使用するには、特殊なネットワークハードウェアおよびソフトウェアが必要となります (セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください)。

A.10.10.

MySQL Cluster を使用するために必要な RAM のサイズはどれくらいですか。ディスクメモリーを使用することはできますか。

以前は、MySQL Cluster はインメモリーのみを使用していました。MySQL 5.1 以降では、MySQL Cluster をディスクに格納する機能も提供されています。(この機能を以前のリリースにバックポートする計画はありません。)詳細は、セクション18.5.12「MySQL Cluster ディスクデータテーブル」を参照してください。

インメモリーの NDB テーブルの場合は、クラスタ内の各データノードで必要となる RAM の容量のおおよその見積もりを取得するために次の式を使用できます。

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

メモリー要件をより正確に計算するには、クラスタデータベースの各テーブルで行ごとに必要となる格納領域 (詳細は、セクション11.7「データ型のストレージ要件」を参照してください) を判別して、それを行数で乗算する必要があります。カラムインデックスについては、次のことを考慮する必要もあります。

  • NDBCLUSTER テーブルに作成される各主キーまたはハッシュインデックスには、レコードごとに 21−25 バイトが必要となります。これらのインデックスは IndexMemory を使用します。

  • 順序付けされた各インデックスでは、DataMemory を使用して、レコードごとに 10 バイトのストレージが必要となります。

  • また、主キーまたは一意のインデックスを作成すると、このインデックスが USING HASH を指定して作成された場合を除き、順序付けされたインデックスが作成されます。言い換えると、次のようになります。

    • 通常、クラスタテーブルの主キーまたは一意のインデックスには、レコードごとに 31 - 35 バイトが使用されます。

    • ただし、主キーまたは一意のインデックスが USING HASH を指定して作成されている場合は、レコードごとに 21 バイトから 25 バイトのみが必要となります。

すべての主キーおよび一意のインデックスに USING HASH を指定して MySQL Cluster のテーブルを作成すると、通常、テーブルの更新がより迅速に実行されます。主キーおよびユニークキーの作成に USING HASH が使用されなかったテーブルへの更新より 20 - 30% 速いことがあります。これは、必要なメモリーが少なくなり (順序付けされたインデックスが作成されないため)、使用される CPU が少なくなる (読み取りおよび (場合によっては) 更新する必要があるインデックスが少なくなるため) ためです。ただし、これは、本来範囲スキャンを使用するクエリーをほかの方法で実行する必要があることも意味し、選択が低速になることがあります。

クラスタのメモリー要件を計算するときに、最新の MySQL 5.6 リリースに付属している ndb_size.pl ユーティリティーが役に立つことがあります。この Perl スクリプトは、現在の (クラスタではない) MySQL データベースに接続して、NDBCLUSTER ストレージエンジンを使用した場合にデータベースで必要となる容量に関する報告を作成します。詳細は、セクション18.4.25「ndb_size.pl — NDBCLUSTER サイズ要件エスティメータ」を参照してください。

すべての MySQL Cluster テーブルには主キーがある必要があることに留意することが非常に重要です。NDB ストレージエンジンは、主キーが定義されていない場合、主キーを自動的に作成します。この主キーは USING HASH を指定せずに作成されます。

ある時点で MySQL Cluster のデータおよびインデックスの格納に使用されているメモリー量を判別するには、ndb_mgm クライアントで REPORT MEMORYUSAGE コマンドを使用します。詳細は、セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。また、使用可能な DataMemory または IndexMemory の 80% が使用されている場合、および使用率が 85%、90% などに達した場合に、警告がクラスタのログに書き込まれます。

A.10.11.

MySQL Cluster に使用できるファイルシステムは何ですか。ネットワークファイルシステムまたはネットワーク共有は使用できますか。

通常、ホストのオペレーティングシステムにネイティブなファイルシステムは、MySQL Cluster で動作します。特定のファイルシステムが MySQL Cluster と特に良好に動作する (またはそれほどよくない) ことがわかった場合は、その知見をMySQL Cluster フォーラムで共有してください。

Windows の場合は、通常の MySQL と同様に、MySQL Cluster に NTFS ファイルシステムを使用することをお勧めします。FAT ファイルシステムまたは VFAT ファイルシステムでは、MySQL Cluster はテストされていません。このため、それらを MySQL または MySQL Cluster に使用することはお勧めしません。

MySQL Cluster はシェアードナッシングソリューションとして実装されています。この背景にある考え方は、1 つのハードウェアの障害によって、複数のクラスタノードの障害、または場合によってはクラスタ全体の障害が引き起こされないようにすることです。このため、ネットワーク共有またはネットワークファイルシステムの使用は、MySQL Cluster ではサポートされません。これは、SAN などの共有ストレージデバイスにも当てはまります。

A.10.12.

MySQL Cluster のノードは、仮想マシン (VMWare、Parallels、Xen によって作成された仮想マシンなど) 内で実行できますか。

MySQL Cluster は MySQL Cluster NDB 7.2 以降で仮想マシンでの使用がサポートされます。現在、Oracle VM を使用してサポートおよびテストが行われています。

一部の MySQL Cluster ユーザーは、ほかの仮想化製品を使用して MySQL Cluster の配備に成功しました。そのような場合、オラクルは MySQL Cluster のサポートを提供できますが、仮想環境に固有の問題についてはその製品のベンダーに問い合わせる必要があります。

A.10.13.

MySQL Cluster データベースにデータを移入しようとしています。ロード処理が予期せずに終了し、次のようなエラーメッセージが表示されます。

「ERROR 1114: The table 'my_cluster_table' is full」

これが発生するのはなぜですか。

原因はすべてのテーブルデータおよびすべてのインデックス (テーブル定義に主キーの定義が含まれていない場合に自動的に作成される、NDB ストレージエンジンによって要求される主キーを含む) のための十分な RAM が、使用しているセットアップで提供されていないことである可能性があります。

すべてのデータノードで同じ容量の RAM が使用されることにも注意してください。クラスタ内のデータノードは、データノードの中で使用可能なメモリーの容量がもっとも少ないノードより多いメモリーを使用することはできないためです。たとえば、クラスタのデータノードをホストしているコンピュータが 4 台あり、そのうちの 3 台がクラスタのデータの格納に 3G バイトの RAM を使用でき、残りのデータノードが 1G バイトの RAM のみを使用できる場合、各データノードは最大 1G バイトを MySQL Cluster のデータおよびインデックスに使用できます。

場合によっては、ndb_mgm -e "ALL REPORT MEMORYUSAGE"DataMemory に大きい空き領域が示されていても、Table is fullというエラーが MySQL クライアントアプリケーションに表示されることがあります。CREATE TABLEMAX_ROWS オプションを使用すると、MySQL Cluster のテーブルのために追加のパーティションを作成して、ハッシュインデックスに使用できるメモリーを増やすように NDB に強制できます。通常、テーブルに格納することが予期されている行数の 2 倍の数値を MAX_ROWS に設定すれば十分です。

同様の理由で、データが大量にロードされたノードで、データノードが再起動される問題が発生することもあります。MySQL Cluster NDB 7.1 以降では、MinFreePct パラメータが追加され、DataMemory および IndexMemory の一部 (デフォルトでは 5%) を再起動で使用するために予約することによって、この問題に対処しています。この予約されたメモリーは、NDB テーブルまたはデータの格納には使用できません。

A.10.14.

MySQL Cluster は TCP/IP を使用しています。これは、1 つ以上のノードをリモートの場所に配置して、インターネット経由で実行できることを意味しますか。

そのような状況でクラスタが確実に実行される可能性はほとんどありません。MySQL Cluster は、100M ビット/秒またはギガビット Ethernet (後者が望ましい) を使用した LAN 環境のような専用の高速接続が保証された状況で実行されることを想定して設計および実装されているためです。これより遅い環境で使用したときのパフォーマンスはテストされておらず保証されません。

また、MySQL Cluster のノード間の通信はセキュアではないことに注意することも重要です。それらは暗号化されておらず、ほかの保護メカニズムによる保護手段も講じられていません。クラスタのもっともセキュアな構成は、外部からクラスタのデータまたは管理ノードに直接アクセスされない、ファイアウォールの内側のプライベートネットワークです。(SQL ノードの場合は、MySQL サーバーのほかのインスタンスの場合と同様の予防措置を取るようにしてください。)詳細は、セクション18.5.11「MySQL Cluster のセキュリティー上の問題」を参照してください。

A.10.15.

MySQL Cluster を使用するために、新しいプログラミング言語またはクエリー言語を学習する必要がありますか。

いいえ。クラスタ自体の管理および構成にはいくつかの特殊なコマンドが使用されますが、次の操作には標準の (My)SQL ステートメントのみが必要となります。

  • テーブルの作成、変更、および削除

  • テーブルデータの挿入、更新、および削除

  • プライマリインデックスおよび一意のインデックスの作成、変更、および削除

MySQL Cluster を設定するには、いくつかの特殊な構成パラメータおよびファイルが必要となります。これらの詳細は、セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください。

クラスタノードの起動、停止などのタスクのために、いくつかの簡単なコマンドが MySQL Cluster 管理クライアント (ndb_mgm) で使用されます。セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。

A.10.16.

MySQL Cluster によってサポートされるプログラミング言語および API は何ですか。

MySQL Cluster は、標準の MySQL サーバーと同じプログラミング API および言語 (ODBC、.Net、MySQL C API、および一般的なスクリプト言語 (PHP、Perl、Python など) のための多数のドライバを含む) をサポートしています。これらの API を使用して記述された MySQL Cluster アプリケーションは、ほかの MySQL アプリケーションと同様に動作します。SQL ステートメントを MySQL サーバー (MySQL Cluster の場合は SQL ノード) に送信して、データの行が含まれている応答を受け取ります。これらの API については、第23章「Connector および APIを参照してください。

MySQL Cluster は、NDB API を使用したアプリケーションプログラミングもサポートしています。これは、MySQL サーバーにアクセスする必要のない、MySQL Cluster のデータへの低レベルの C++ インタフェースを提供します。The NDB APIを参照してください。また、多くの NDBCLUSTER 管理関数が C 言語の MGM API によって提供されています。詳細は、The MGM APIを参照してください。

MySQL Cluster (NDB 7.1 以降) は、ClusterJ を使用した Java アプリケーションプログラミングもサポートしています。これは、セッションおよびトランザクションを使用して、データのドメインオブジェクトモデルをサポートします。詳細は、Java and NDB Clusterを参照してください。

MySQL Cluster (NDB 7.2 以降) には、memcached のサポートが追加され、開発者は memcached インタフェースを使用して MySQL Cluster に格納されているデータにアクセスできます。詳細は、ndbmemcache—Memcache API for NDB Clusterを参照してください。

MySQL Cluster NDB 7.3 には、MySQL Cluster をデータストアとして使用する、Node.js に対して記述された NoSQL アプリケーションをサポートするアダプタが追加されました。詳細は、MySQL NoSQL Connector for JavaScriptを参照してください。

A.10.17.

MySQL Cluster には管理ツールが含まれていますか。

MySQL Cluster には、基本的な管理機能を実行するためのコマンド行クライアントが含まれています。セクション18.4.5「ndb_mgm — MySQL Cluster 管理クライアント」およびセクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。

MySQL Cluster NDB 7.0 以降は MySQL Cluster Manager によってもサポートされます。これは別個の製品であり、ローリング再起動、構成の変更などの MySQL Cluster の多くの管理タスクを自動化できる拡張されたコマンド行インタフェースが提供されます。MySQL Cluster Manager については、MySQL™ Cluster Manager 1.3.6 User Manualを参照してください。

MySQL Cluster NDB 7.3 では、MySQL Cluster ソフトウェア配布の一部として、MySQL Cluster を設定および配備するためのブラウザベースのグラフィカルな Auto-Installer が導入されました。詳細は、セクション18.2.1「MySQL Cluster Auto-Installer」を参照してください。

A.10.18.

MySQL Cluster を使用しているときに、エラーメッセージまたは警告メッセージの意味を確認するにはどうすればよいですか。

これを行うことができる方法は 2 つあります。

  • エラー状態または警告状態を通知された直後に、mysql クライアント内で SHOW ERRORS または SHOW WARNINGS を使用します。

  • システムのシェルプロンプトで、perror --ndb error_code を使用します。

A.10.19.

MySQL Cluster はトランザクションセーフですか。どのような分離レベルがサポートされますか。

はいNDB ストレージエンジンを指定して作成されたテーブルの場合は、トランザクションがサポートされます。現在、MySQL Cluster では READ COMMITTED トランザクション分離レベルのみがサポートされます。

A.10.20.

MySQL Cluster によってサポートされるストレージエンジンは何ですか。

MySQL でのクラスタリングは、NDB ストレージエンジンによってのみサポートされます。つまり、MySQL Cluster のノード間でテーブルを共有するには、ENGINE=NDB (または同等のオプション ENGINE=NDBCLUSTER) を使用してテーブルを作成する必要があります。

MySQL Cluster で使用されている MySQL サーバーに、ほかのストレージエンジン (InnoDBMyISAM など) を使用するテーブルを作成することはできますが、それらのテーブルは NDB を使用していないため、クラスタリングに参加しません。そのような各テーブルはそれが作成された MySQL サーバーインスタンスに厳密にローカルなテーブルとなります。

A.10.21.

壊滅的な障害が発生した場合 (たとえば、街全体が停電かつUPS の障害が発生した場合)、すべてのデータが失われますか。

コミットされたすべてのトランザクションはログ記録されます。このため、大災害が起こった場合に一部のデータが失われることはありますが、それはごく限定的なものとなります。データの損失は、トランザクションごとの操作の数を最小限にすることによって、さらに減らすことができます。(どのような場合でも、1 つのトランザクションで多数の操作を実行するのはよい考えではありません。)

A.10.22.

MySQL Cluster では FULLTEXT インデックスを使用できますか。

現在、FULLTEXT インデックスは、InnoDB ストレージエンジン (MySQL 5.6.4 以降) および MyISAM ストレージエンジンのみによってサポートされています。詳細は、セクション12.9「全文検索関数」を参照してください。

A.10.23.

単一のコンピュータ上で複数のノードを実行できますか。

実行できますが常に推奨できるとは限りません。クラスタを実行する主な理由の 1 つは冗長性を持たせるためです。この冗長性の利点を完全に享受するには、各ノードを別個のマシン上に配置してください。単一のマシンに複数のノードを配置した場合、そのマシンで障害が発生したときに、それらのすべてのノードが失われます。このため、単一のマシンで複数のデータノードを実行する場合は、そのマシンの障害によってノードグループのすべてのデータノードが失われることがないように設定することが非常に重要です。

MySQL Cluster は低コスト (または無料) のオペレーティングシステムがロードされた一般的なハードウェアで実行できるため、追加のマシンを 1 台または 2 台購入する出費は、ミッションクリティカルなデータを保護するためには十分に価値があります。管理ノードを実行するクラスタホストの要件は最低限のものであることにも注意してください。このタスクは、300 MHz の Pentium または同等の CPU、オペレーティングシステムのための十分な RAM、および ndb_mgmd プロセスと ndb_mgm プロセスのための少量のオーバーヘッドに対応した装備があれば実行できます。

複数の CPU、コア、またはその両方を持つ単一のホストで、複数のクラスタデータノードを実行することは容認できます。MySQL Cluster NDB 7.0 以降では、そのようなシステムで使用することが意図された、マルチスレッドバージョンのデータノードのバイナリも提供されています。詳細は、セクション18.4.3「ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)」を参照してください。

同じマシン上でデータノードと SQL ノードを同時に実行できる場合もあります。そのような配置での実行状態は、さまざまな要因 (コアおよび CPU の数、データノードおよび SQL ノードのプロセスが使用できるディスクおよびメモリーの容量など) によって異なります。そのような構成を計画する場合は、これらの要因を考慮する必要があります。

A.10.24.

MySQL Cluster を再起動せずにデータノードを追加できますか。

クラスタをオフラインにせずに、実行されている MySQL Cluster に新しいデータノードを追加できます。詳細は、セクション18.5.13「MySQL Cluster データノードのオンライン追加」を参照してください。

ほかのタイプの MySQL Cluster ノードの場合は、ローリング再起動を行えばよいだけです (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

A.10.25.

MySQL Cluster を使用するときに、注意するべき制限はありますか。

MySQL Cluster NDB 7.3 以降の NDB テーブルの制限には次のものがあります。

  • 一時テーブルはサポートされません。ENGINE=NDB または ENGINE=NDBCLUSTER を使用した CREATE TEMPORARY TABLE ステートメントは、エラーが発生して失敗します。

  • NDBCLUSTER テーブルでサポートされるユーザー定義のパーティション化のタイプは、KEY および LINEAR KEY のみです。ほかのパーティショニングタイプを使用して NDB テーブルを作成しようとすると、エラーが発生して失敗します。

  • FULLTEXT インデックスはサポートされません。

  • インデックスのプリフィクスはサポートされません。インデックスを作成できるのは完全なカラムのみです。

  • 空間インデックスはサポートされません (空間カラムは使用できます)。セクション11.5「空間データの拡張」を参照してください。

  • 部分的なトランザクションおよび部分的なロールバックのサポートは、ほかのトランザクションストレージエンジン (個別のステートメントをロールバックできる InnoDB など) と同等です。

  • テーブルごとに許可される属性の最大数は 512 個です。属性名は 31 文字以内である必要があります。各テーブルで、テーブル名とデータベース名を合わせた最大長は 122 文字です。

  • テーブルの行の最大サイズは、BLOB 値をカウントせずに 14K バイトです。

    NDB テーブルごとの行数の制限はありません。テーブルサイズの制限は多くの要因によって異なり、各データノードで使用できる RAM の容量に特に関係しています。

MySQL Cluster の制限の完全なリストについては、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。セクション18.1.6.11「MySQL Cluster NDB 7.3 で解決された以前の MySQL Cluster の問題」も参照してください。

A.10.26.

MySQL Cluster では外部キーはサポートされますか。

MySQL Cluster NDB 7.3 では、InnoDB ストレージエンジンと同等の外部キー制約のサポートが追加されました。詳細は、セクション1.8.3.2「FOREIGN KEY の制約」およびセクション13.1.17.2「外部キー制約の使用」を参照してください。外部キーのサポートが必要なアプリケーションの場合は、MySQL Cluster NDB 7.3 以降を使用してください。

A.10.27.

既存の MySQL データベースを MySQL Cluster にインポートするにはどうすればよいですか。

ほかのバージョンの MySQL の場合と同様に、データベースを MySQL Cluster にインポートできます。この FAQ の各所で説明されている制限以外の唯一の特別な要件は、クラスタに含まれるテーブルが NDB ストレージエンジンを使用する必要があることです。これは、ENGINE=NDB または ENGINE=NDBCLUSTER を指定してテーブルを作成する必要があることを意味します。

ほかのストレージエンジンを使用しているテーブルを、1 つ以上の ALTER TABLE ステートメントを使用して、NDBCLUSTER に変更することもできます。ただし、変更を行う前に、テーブルの定義が NDBCLUSTER ストレージエンジンと互換性がある必要があります。MySQL 5.6 では、追加の回避策も必要となります。詳細は、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。

A.10.28.

MySQL Cluster のノードはどのようにして相互にやり取りしますか。

クラスタのノードは、3 種類の転送メカニズム (TCP/IP、SHM (共有メモリー)、および SCI (スケーラブルコヒーラントインタフェース)) を使用して通信できます。使用可能な場合、同じクラスタホスト上にあるノード間では SHM がデフォルトで使用されます。ただし、これは実験的とみなされます。SCI は、スケーラブルなマルチプロセッサシステムを構築するために使用される高速 (1 Gbps 以上) で高可用性のプロトコルであり、特殊なハードウェアおよびドライバが必要となります。MySQL Cluster の転送メカニズムとして SCI を使用する方法については、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。

A.10.29.

アービトレータとは何ですか。

クラスタ内の 1 つ以上のデータノードで障害が発生した場合、相互に認識できないクラスタデータノードが発生することがあります。実際に、2 つのセットのデータノードがネットワークのパーティション化で別々に分離されることがあります (スプリットブレインシナリオとも呼ばれます)。各セットのデータノードがクラスタ全体のように動作しようとするため、このタイプの状況は好ましくありません。競合するデータノードのセットのいずれかを選択するために、アービトレータが必要となります。

少なくとも 1 つのノードグループのすべてのデータノードが存続して場合、クラスタの単一のサブセットが独自に機能するクラスタを形成できないため、ネットワークのパーティション化は問題とはなりません。本当の問題はすべてのノードが存続している単一のノードグループがない場合に発生し、その場合はネットワークのパーティション化 (スプリットブレインシナリオ) が発生する可能性があります。そしてアービトレータが必要となります。すべてのクラスタノードは、同じノードをアービトレータとして認識しますが、通常、これは管理サーバーです。ただし、クラスタ内の MySQL サーバーのいずれかを代わりにアービトレータとして動作するように構成できます。アービトレータは、クラスタノードの最初のセットがアクセスすることを受け入れ、残りのセットにシャットダウンするように指示します。アービトレータの選択は、MySQL サーバーおよび管理サーバーノードの ArbitrationRank 構成パラメータによって制御されます。MySQL Cluster NDB 7.0.7 以降では、ArbitrationRank 構成パラメータを使用してアービトレータの選択処理を制御することもできます。これらのパラメータについては、セクション18.3.2.5「MySQL Cluster 管理サーバーの定義」を参照してください。

アービトレータの役割によって、指定されたホストに重い要求が課されることはないため、アービトレータのホストはこの目的のために特別に処理が速いマシン、または追加のメモリーがあるマシンである必要はありません。

A.10.30.

MySQL Cluster によってサポートされるデータ型を何ですか。

MySQL Cluster は MySQL の通常のデータ型 (MySQL の空間拡張に関連付けられている型を含む) をすべてサポートしています。ただし、NDB ストレージエンジンは空間インデックスをサポートしていません。(空間インデックスは MyISAM によってのみサポートされます。詳細は、セクション11.5「空間データの拡張」を参照してください。)また、NDB テーブルとともに使用された場合、インデックスに関していくつかの違いがあります。

注記

MySQL Cluster のディスクデータテーブル (つまり、TABLESPACE ... STORAGE DISK ENGINE=NDB または TABLESPACE ... STORAGE DISK ENGINE=NDBCLUSTER を指定して作成されたテーブル) には固定長の行のみが格納されています。これは、(たとえば) VARCHAR(255) カラムが含まれている各ディスクデータテーブルレコードで、実際に格納される文字数に関係なく、255 文字 (テーブルに使用されている文字セットおよび照合順序に必要となります) の領域が必要となることを意味します。

これらの問題については、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。

A.10.31.

MySQL Cluster を起動および停止するにはどうすればよいですか。

クラスタ内の各ノードを次の順序で個別に起動する必要があります。

  1. ndb_mgmd コマンドを使用して、管理ノードを起動します。

    -f オプションまたは --config-file オプションを指定して、構成ファイルのある場所を管理ノードに通知する必要があります。

  2. ndbd コマンドを使用して、各データノードを起動します。

    データノードが管理サーバーに接続する方法を認識するように、-c オプションまたは --ndb-connectstring オプションを指定して各データノードを起動する必要があります。

  3. 任意の起動スクリプト (mysqld_safe など) を使用して各 MySQL サーバー (SQL ノード) を起動します。

    各 MySQL サーバーは、--ndbcluster オプションおよび --ndb-connectstring オプションを指定して起動する必要があります。これらのオプションによって、NDBCLUSTER ストレージエンジンのサポート、および管理サーバーに接続する方法が mysqld で有効になります。

影響を受けるノードがあるマシンのシステムシェルで、これらの各コマンドを実行する必要があります。(そのマシンを物理的にその場で操作する必要はありません。リモートログインシェルをこの目的に使用できます。)クラスタが実行されていることを確認するには、管理ノードが収容されているマシンで NDB 管理クライアント ndb_mgm を起動して、SHOW コマンドまたは ALL STATUS コマンドを発行します。

実行されているクラスタをシャットダウンするには、管理クライアントで SHUTDOWN コマンドを発行します。または、システムシェルに次のコマンドを入力できます。

shell> ndb_mgm -e "SHUTDOWN"

(この例の引用符はオプションです。-e オプションの後ろのコマンド文字列にスペースがないためです。また、管理クライアントのほかのコマンドと同様に、SHUTDOWN コマンドでは大文字/小文字が区別されません。)

これらのコマンドのいずれかによって、ndb_mgmndb_mgm、および ndbd プロセスが正常に終了します。SQL ノードとして実行されている MySQL サーバーは、mysqladmin shutdown を使用して停止できます。

詳細は、セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」およびセクション18.2.7「MySQL Cluster の安全なシャットダウンと再起動」を参照してください。

A.10.32.

MySQL Cluster をシャットダウンすると、MySQL Cluster のデータはどうなりますか。

クラスタのデータノードによってメモリーに保持されていたデータがディスクに書き込まれ、次回クラスタが起動されたときにメモリーにリロードされます。

A.10.33.

MySQL Cluster に複数の管理ノードを使用することはよい考えですか。

フェイルセーフとして役に立つことがあります。特定の時点でクラスタを制御しているのは 1 つの管理ノードのみですが、1 つの管理ノードをプライマリとして構成し、プライマリ管理ノードで障害が発生した場合に、1 つ以上の追加の管理ノードが引き継ぐようにすることができます。

MySQL Cluster の管理ノードを構成する方法については、セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください。

A.10.34.

単一の MySQL Cluster に、異なる種類のハードウェアおよびオペレーティングシステムを混在させることはできますか。

はい。すべてのマシンおよびオペレーティングシステムが同じエンディアン (すべてがビッグエンディアンまたはすべてがリトルエンディアン) であれば可能です。

異なる MySQL Cluster リリースのソフトウェアを各ノードに使用することもできます。ただし、ローリングアップグレードの手順の一部としてのみこれをサポートしています (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

A.10.35.

単一のホスト上で 2 つのデータノードを実行できますか。2 つの SQL ノードは実行できますか。

はい。実行できます。複数のデータノードの場合は、各ノードで別のデータディレクトリを使用することをお勧めします (必須ではありません)。単一のマシン上で複数の SQL ノードを実行する場合は、mysqld の各インスタンスで別の TCP/IP ポートを使用する必要があります。ただし、MySQL 5.6 では、1 台のマシンで特定のタイプの複数のクラスタノードを実行することは推奨されず、本番での使用はサポートされません。

また、ndbd プロセスおよび mysqld プロセスはメモリーで競合することがあるため、同じホスト上でデータノードおよび SQL ノードを一緒に実行しないことをお勧めします。

A.10.36.

MySQL Cluster ではホスト名を使用できますか。

はい。クラスタのホストに DNS および DHCP を使用できます。ただし、アプリケーションがファイブナイン可用性を要求する場合は、固定 (数値) IP アドレスを使用してください。クラスタホスト間通信を DNS、DHCP などのサービスに依存させると、潜在的な障害点が増えるためです。

A.10.37.

MySQL Cluster では IPv6 はサポートされますか。

IPv6 は SQL ノード (MySQL サーバー) 間の接続ではサポートされますが、ほかのすべてのタイプの MySQL Cluster ノード間の接続には IPv4 を使用する必要があります。

具体的には、これは、MySQL Cluster 間のレプリケーションには IPv6 を使用できるが、同じ MySQL Cluster 内のノード間の接続には IPv4 を使用する必要があることを意味します。詳細は、セクション18.6.3「MySQL Cluster レプリケーションの既知の問題」を参照してください。

A.10.38.

複数の MySQL サーバーを持つ MySQL Cluster で MySQL ユーザーを管理するにはどうすればよいですか。

通常、MySQL のユーザーアカウントおよび権限は、同じ MySQL Cluster にアクセスする異なる MySQL サーバー間で自動的に伝播されません。MySQL Cluster NDB 7.2 以降では、MySQL Cluster は権限の配布のサポートを提供しています。権限の配布は自動的に有効になりませんが、MySQL Cluster のドキュメントで説明されている次の手順を使用して有効にできます。詳細は、セクション18.5.14「MySQL Cluster の配布された MySQL 権限」を参照してください。

A.10.39.

SQL ノードの 1 つで障害が発生した場合に、クエリーの送信を続けるにはどうすればよいですか。

MySQL Cluster は SQL ノード間でどのような種類の自動フェイルオーバーも提供していません。SQL ノードを失ったときの処理、およびそれらの間のフェイルオーバーを行うように、アプリケーションで準備している必要があります。

A.10.40.

MySQL Cluster をバックアップおよびリストアするにはどうすればよいですか。

MySQL Cluster 管理クライアントおよび ndb_restore プログラムの NDB にネイティブなバックアップおよびリストア機能を使用できます。セクション18.5.3「MySQL Cluster のオンラインバックアップ」およびセクション18.4.20「ndb_restore — MySQL Cluster バックアップのリストア」を参照してください。

このために mysqldump および MySQL サーバーで提供されている従来の機能を使用することもできます。詳細は、セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。

A.10.41.

エンジェルプロセスとは何ですか。

このプロセスは、データノードプロセスをモニターし、必要に応じて再起動を試みます。ndbd を起動したあとに、システムでアクティブなプロセスのリストをチェックすると、その名前で実行されているプロセスが実際には 2 つあることを確認できます (簡潔にするために、出力では ndb_mgmd および ndbd を省略しました)。

shell> ./ndb_mgmdshell> ps aux | grep ndbme 23002 0.0 0.0 122948 3104 ? Ssl 14:14 0:00 ./ndb_mgmd
me 23025 0.0 0.0 5284 820 pts/2 S+ 14:14 0:00 grep ndb
shell> ./ndbd -c 127.0.0.1 --initialshell> ps aux | grep ndbme 23002 0.0 0.0 123080 3356 ? Ssl 14:14 0:00 ./ndb_mgmd
me 23096 0.0 0.0 35876 2036 ? Ss 14:14 0:00 ./ndbd -c 127.0.0.1 --initial
me 23097 1.0 2.4 524116 91096 ? Sl 14:14 0:00 ./ndbd -c 127.0.0.1 --initial
me 23168 0.0 0.0 5284 812 pts/2 R+ 14:15 0:00 grep ndb

メモリーおよび CPU の使用量が 0 と表示されている ndbd プロセスがエンジェルプロセスです。実際には、もちろんそれぞれにごく少量が使用されます。これは、メインの ndbd プロセス (データを実際に処理するプライマリデータノードプロセス) が実行されているかどうかを単純にチェックします。許可されている場合 (たとえば、StopOnError 構成パラメータが false に設定されている場合。セクション18.3.3.1「MySQL Cluster データノードの構成パラメータ」を参照してください)、エンジェルプロセスはプライマリデータノードプロセスを再起動しようとします。

A.11 MySQL 5.6 FAQ: MySQL の中国語、日本語、および韓国語の文字セット

この一連のよくある質問は、CJK (中国語、日本語、韓国語) の問題に関する多くの問い合わせに対応している MySQL のサポートグループおよび開発グループの経験から得られたものです。

A.11.1. MySQL で使用できる CJK 文字セットはどの文字セットですか。
A.11.2. CJK 文字をテーブルに挿入しました。SELECT でそれらが「?」文字として表示されるのはなぜですか。
A.11.3. Big5 中国語文字セットを使用する場合は、どのような問題に注意するべきですか。
A.11.4. 日本語文字セットの変換が失敗するのはなぜですか。
A.11.5. SJIS の 81CA を cp932 に変換する場合はどうすればよいですか。
A.11.6. MySQL では円 (¥) 記号をどのように表しますか。
A.11.7. MySQL で韓国語文字セットを使用する場合に注意する問題はありますか。
A.11.8. なぜ「Incorrect string value」というエラーメッセージが表示されるのですか。
A.11.9. Access、PHP、またはその他の API を使用したアプリケーションの GUI フロントエンドまたはブラウザで、CJK 文字が正しく表示されないのはなぜですか。
A.11.10. MySQL 5.6 にアップグレードしました。文字セットに関して、MySQL 4.0 の動作に戻すにはどうすればよいですか。
A.11.11. CJK 文字での LIKE 検索および FULLTEXT 検索が失敗することがあるのはなぜですか。
A.11.12. 文字 X がすべての文字セットで使用可能であるかどうかを判別するにはどうすればよいですか。
A.11.13. CJK 文字列が Unicode で間違ってソートされるのはなぜですか。(I)
A.11.14. CJK 文字列が Unicode で間違ってソートされるのはなぜですか。(II)
A.11.15. 補助文字が MySQL で拒否されるのはなぜですか。
A.11.16. 「CJKV」にするべきではありませんか。
A.11.17. MySQL では CJK 文字をデータベース名およびテーブル名に使用できますか。
A.11.18. MySQL マニュアルの中国語版、日本語版、および韓国語版はどこにありますか。
A.11.19. MySQL での CJK および関連する問題についての支援はどこで受けることができますか。

A.11.1.

MySQL で使用できる CJK 文字セットはどの文字セットですか。

CJK 文字セットのリストは、MySQL のバージョンによって異なることがあります。たとえば、gb18030 文字セットは MySQL 5.7.4 より前はサポートされていませんでした。ただし、INFORMATION_SCHEMA.CHARACTER_SETS 表のすべてのエントリの DESCRIPTION カラムには適用可能な言語の名前が表示されるため、次のクエリーを使用して Unicode 以外のすべての CJK 文字セットの最新のリストを取得できます。

mysql> SELECT CHARACTER_SET_NAME, DESCRIPTION -> FROM INFORMATION_SCHEMA.CHARACTER_SETS -> WHERE DESCRIPTION LIKE '%Chin%' -> OR DESCRIPTION LIKE '%Japanese%' -> OR DESCRIPTION LIKE '%Korean%' -> ORDER BY CHARACTER_SET_NAME;+--------------------+---------------------------------+
| CHARACTER_SET_NAME | DESCRIPTION |
+--------------------+---------------------------------+
| big5 | Big5 Traditional Chinese |
| cp932 | SJIS for Windows Japanese |
| eucjpms | UJIS for Windows Japanese |
| euckr | EUC-KR Korean |
| gb18030 | China National Standard GB18030 |
| gb2312 | GB2312 Simplified Chinese |
| gbk | GBK Simplified Chinese |
| sjis | Shift-JIS Japanese |
| ujis | EUC-JP Japanese |
+--------------------+---------------------------------+
9 rows in set (0.01 sec)

(詳細は、セクション21.1「INFORMATION_SCHEMA CHARACTER_SETS テーブル」を参照してください。)

MySQL は中華人民共和国の正式な文字セットである GB 文字セット (Guojia BiaozhunNational Standard、または Simplified Chinese) の 3 つのバリアント (gb2312gbk、および gb18030 (MySQL 5.7.4 で追加されました)) をサポートしています。

ユーザーが gbk の文字を gb2312 に挿入しようとすることがありますが、これはほとんどの場合動作します。gbkgb2312 のスーパーセットであるためです。ただし、より珍しい漢字を挿入しようとすると動作しません。(例については、Bug #16072 を参照してください)。

ここでは、gb2312 または gbk で正当な文字を明らかにして、正式なドキュメントへの参照を示します。gb2312 または gbk のバグを報告する前に、これらのリファレンスを確認してください。

  • MySQL の gbk は、実際にはMicrosoft コードページ 936です。これは、正式な gbk とは文字 A1A4 (中黒)、A1AA (エムダッシュ)、A6E0-A6F5、および A8BB-A8C0 が異なります。

  • gbk/Unicode マッピングのリストについては、http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT を参照してください。

A.11.2.

CJK 文字をテーブルに挿入しました。SELECT でそれらが?文字として表示されるのはなぜですか。

この問題は、通常、アプリケーションプログラムまたはオペレーティングシステムの設定と MySQL の設定が一致していないことが原因です。これらのタイプの問題を修正するための一般的な手順を次に示します。

  • 使用している MySQL のバージョンを確認します

    これを判別するには、SELECT VERSION(); ステートメントを使用します。

  • 意図した文字セットがデータベースで実際に使用されていることを確認します

    ユーザーは多くの場合、クライアントの文字セットはサーバーの文字セットまたは表示のために使用される文字セットと常に同じであると考えます。ただし、これらは両方とも間違った想定です。SHOW CREATE TABLE tablename の結果をチェックするか、次のステートメントを使用することによって確認できます。

    SELECT character_set_name, collation_name FROM information_schema.columns WHERE table_schema = your_database_name AND table_name = your_table_name AND column_name = your_column_name;
  • 正しく表示されない文字の 16 進値を判別します

    テーブル table_name のカラム column_name のこの情報を取得するには、次のクエリーを使用します。

    SELECT HEX(column_name)
    FROM table_name;

    3F? 文字のエンコードです。これは、? が実際にカラムに格納される文字であることを意味します。これは、ほとんどの場合、特定の文字をクライアントの文字セットからターゲットの文字セットに変換するときの問題のために発生します。

  • ラウンドトリップが可能であることを確認します (つまり、literal (または _introducer hexadecimal-value) を選択すると、結果として literal が取得される)

    たとえば、日本語のカタカナ文字 Pe () はすべての CJK 文字セットに存在し、コードポイント値 (16 進コーディング) は 0x30da です。この文字のラウンドトリップをテストするには、次のクエリーを使用します。

    SELECT 'ペ' AS `ペ`; 

    結果も「ペ」ではない場合、ラウンドトリップは失敗しました。

    そのような失敗に関するバグレポートの場合は、SELECT HEX('ペ'); も試すように要請されることがあります。これにより、クライアントのエンコードが正しいかどうかを判断できます。

  • 問題が MySQL 以外のブラウザまたはほかのアプリケーションの問題ではないことを確認します

    このタスクを行うには、mysql クライアントプログラム (Windows の場合: mysql.exe) を使用します。mysql では正しく表示されるが、アプリケーションでは表示されない場合、問題はシステム設定が原因である可能性があります。

    設定を確認するには、次のような出力が表示される SHOW VARIABLES ステートメントを使用します。

    mysql> SHOW VARIABLES LIKE 'char%';+--------------------------+----------------------------------------+
    | Variable_name | Value |
    +--------------------------+----------------------------------------+
    | character_set_client | utf8 |
    | character_set_connection | utf8 |
    | character_set_database | latin1 |
    | character_set_filesystem | binary |
    | character_set_results | utf8 |
    | character_set_server | latin1 |
    | character_set_system | utf8 |
    | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
    +--------------------------+----------------------------------------+
    8 rows in set (0.03 sec)

    これらは、西洋諸国のサーバー (latin1 は西ヨーロッパ文字セットであり、MySQL のデフォルトです) に接続される国際業務用のクライアントの典型的な文字セット設定です (utf8 Unicode が使用されています)。

    Latin よりも Unicode (通常、Unix での utf8 バリアント、および Windows での ucs2 バリアント) の方が望ましいですが、オペレーティングシステムのユーティリティーで最適にサポートされる文字セットではないことがあります。多くの Windows ユーザーは、Microsoft の文字セット (日本語 Windows 用の cp932 など) が適当であると判断します。

    サーバーの設定を制御できず、基盤となっているコンピュータがわからない場合は、自分の国の一般的な文字セットに変更することを試してください (euckr = 韓国、gb18030gb2312、または gbk = 中華人民共和国、big5 = 台湾、sjisujiscp932、または eucjpms = 日本、ucs2 または utf8 = すべての国)。通常、クライアント、接続、および結果の設定のみを変更する必要があります。この 3 つを一度にすべて変更する簡単なステートメントがSET NAMES です。例:

    SET NAMES 'big5';

    設定が正しい場合は、my.cnf または my.ini を編集することによってそれを永続的なものにできます。たとえば、次のような行を追加できます。

    [mysqld]
    character-set-server=big5
    [client]
    default-character-set=big5

    アプリケーションで使用されている API 構成の設定に問題があることもあります。詳細は、「GUI フロントエンドまたはブラウザで CJK 文字が正しく表示されないのはなぜですか」を参照してください。

A.11.3.

Big5 中国語文字セットを使用する場合は、どのような問題に注意するべきですか。

MySQL は、香港および台湾 (中華民国) で一般的な Big5 文字セットをサポートしています。MySQL の big5 は、実際には、本来の big5 文字セットと非常に似ている Microsoft コードページ 950 です。この文字セットは MySQL バージョン 4.1.16 / 5.0.16 以降で変更されています (Bug #12476 のため)。たとえば、次のステートメントは最新のバージョンの MySQL では動作しますが、古いバージョンでは動作しません。

mysql> CREATE TABLE big5 (BIG5 CHAR(1) CHARACTER SET BIG5);Query OK, 0 rows affected (0.13 sec)
mysql> INSERT INTO big5 VALUES (0xf9dc);Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM big5;+------+
| big5 |
+------+
| 嫺 |
+------+
1 row in set (0.02 sec)

HKSCS 拡張を追加する機能要求は申請されています。この拡張を必要とするユーザーの場合、Bug #13577 のための推奨パッチが役に立つことがあります。

A.11.4.

日本語文字セットの変換が失敗するのはなぜですか。

MySQL は、sjisujiscp932、および eucjpms 文字セットと Unicode をサポートしています。一般的なニーズは文字セット間で変換を行うことです。たとえば、Unix のサーバー (通常は sjis または ujis が使用されます) と Windows のクライアント (通常は cp932 が使用されます) を使用している場合があります。

次の変換表で、ucs2 カラムは変換前を表し、sjiscp932ujis、および eucjpms カラムは変換後を表しています。つまり、後ろの 4 つのカラムは、CONVERT(ucs2) を使用するか、値が含まれている ucs2 カラムを sjiscp932ujis、または eucjpms カラムに割り当てたときの 16 進数の結果を示しています。

文字名ucs2sjiscp932ujiseucjpms
BROKEN BAR (破断線)00A63F3F8FA2C33F
FULLWIDTH BROKEN BAR (全角破断線)FFE43FFA553F8FA2
YEN SIGN (円記号)00A53F3F203F
FULLWIDTH YEN SIGN (全角円記号)FFE5818F818FA1EF3F
TILDE (チルダ)007E7E7E7E7E
OVERLINE (オーバーライン)203E3F3F203F
HORIZONTAL BAR (水平線)2015815C815CA1BDA1BD
EM DASH (エムダッシュ)20143F3F3F3F
REVERSE SOLIDUS (リバースソリダス)005C815F5C5C5C
FULLWIDTH "" (全角リバースソリダス)FF3C3F815F3FA1C0
WAVE DASH (波ダッシュ)301C81603FA1C13F
FULLWIDTH TILDE (全角チルダ)FF5E3F81603FA1C1
DOUBLE VERTICAL LINE (双柱)201681613FA1C23F
PARALLEL TO (平行)22253F81613FA1C2
MINUS SIGN (マイナス記号)2212817C3FA1DD3F
FULLWIDTH HYPHEN-MINUS (全角ハイフンマイナス)FF0D3F817C3FA1DD
CENT SIGN (セント記号)00A281913FA1F13F
FULLWIDTH CENT SIGN (全角セント記号)FFE03F81913FA1F1
POUND SIGN (ポンド記号)00A381923FA1F23F
FULLWIDTH POUND SIGN (全角ポンド記号)FFE13F81923FA1F2
NOT SIGN (否定記号)00AC81CA3FA2CC3F
FULLWIDTH NOT SIGN (全角否定記号)FFE23F81CA3FA2CC

では、この表の次の部分について考えてみましょう。

 ucs2sjiscp932
NOT SIGN (否定記号)00AC81CA3F
FULLWIDTH NOT SIGN (全角否定記号)FFE23F81CA

これは、MySQL が NOT SIGN (Unicode の U+00AC) を sjis のコードポイント 0x81CA および cp932 のコードポイント 3F に変換することを意味します (3F は疑問符 (?) であり、変換を実行できないときに常に使用される文字です)。

A.11.5.

SJIS の 81CAcp932 に変換する場合はどうすればよいですか。

答えは?です。これについては深刻な苦情が寄せられています。多くのユーザーは、sjis81CA (NOT SIGN)cp93281CA (FULLWIDTH NOT SIGN) になるような緩い変換を望んでいます。この動作に変更することが検討されています。

A.11.6.

MySQL では円 (¥) 記号をどのように表しますか。

いくつかのバージョンの日本語文字セット (sjis および euc の両方) では 5Cリバースソリダス (\。バックスラッシュとも呼ばれます) として扱われ、ほかの文字セットでは円記号 (¥) として扱われるため、問題が発生します。

MySQL は JIS (Japanese Industrial Standards) 標準に記述されている 1 つのバージョンのみに従っています。MySQL では 5C は常にリバースソリダス (\) です。

A.11.7.

MySQL で韓国語文字セットを使用する場合に注意する問題はありますか。

理論的には、複数のバージョンの euckr (Extended Unix Code Korea) 文字セットがありますが、認識されている問題は 1 つだけです。

コードポイント 0x5cウォン記号 () である EUC-KR のKS-Romanバリアントではなく、コードポイント 0x5c がリバースソリダス (つまり、\) である EUC-KR のASCIIバリアントが使用されています。これは、Unicode の U+20A9euckr に変換できないことを意味します。

mysql> SELECT -> CONVERT('₩' USING euckr) AS euckr, -> HEX(CONVERT('₩' USING euckr)) AS hexeuckr;+-------+----------+
| euckr | hexeuckr |
+-------+----------+
| ? | 3F |
+-------+----------+
1 row in set (0.00 sec)

A.11.8.

なぜ「Incorrect string value」というエラーメッセージが表示されるのですか。

説明のために、1 つの Unicode (ucs2) カラムおよび 1 つの中国語 (gb2312) カラムを持つテーブルを作成します。

mysql> CREATE TABLE ch -> (ucs2 CHAR(3) CHARACTER SET ucs2, -> gb2312 CHAR(3) CHARACTER SET gb2312);Query OK, 0 rows affected (0.05 sec)

両方のカラムに珍しい文字「汌」を挿入することを試みます。

mysql> INSERT INTO ch VALUES ('A汌B','A汌B');Query OK, 1 row affected, 1 warning (0.00 sec)

警告が報告されました。次のステートメントを使用してその内容を確認します。

mysql> SHOW WARNINGS\G*************************** 1. row *************************** Level: Warning Code: 1366
Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1
1 row in set (0.00 sec)

gb2312 カラムのみに関する警告でした。

mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;
+-------+--------------+--------+-------------+
| ucs2 | HEX(ucs2) | gb2312 | HEX(gb2312) |
+-------+--------------+--------+-------------+
| A汌B | 00416C4C0042 | A?B | 413F42 |
+-------+--------------+--------+-------------+
1 row in set (0.00 sec)

いくつかのことを説明する必要があります。

  1. エラーではなく警告であることが MySQL の特徴です。あきらめずにできることをして最善の結果を得ることが試みられます。

  2. 「汌」という文字は gb2312 文字セットにありません。この問題については前に説明しました。

  3. 古いバージョンの MySQL を使用している場合は、別のメッセージが表示される可能性があります。

  4. sql_mode=TRADITIONAL を設定している場合は、警告ではなくエラーメッセージが表示されます。

A.11.9.

Access、PHP、またはその他の API を使用したアプリケーションの GUI フロントエンドまたはブラウザで、CJK 文字が正しく表示されないのはなぜですか。

mysql クライアント (Windows: mysql.exe) を使用してサーバーに直接接続し、同じクエリーをそこで試してください。mysql が正常に応答する場合、問題はアプリケーションインタフェースで初期化が必要であることである可能性があります。mysqlSHOW VARIABLES LIKE 'char%'; ステートメント使用して、使用される文字セットを確認します。Access を使用している場合は、Connector/ODBC を使用して接続することがほとんどです。この場合は、Configuring Connector/ODBCを確認してください。たとえば、big5 を使用している場合は、SET NAMES 'big5' と入力します。(この場合「;」は必要ありません)。ASP を使用している場合は、コードに SET NAMES を追加する必要があることがあります。過去に作成された例を次に示します。

<%
Session.CodePage=0
Dim strConnection
Dim Conn
strConnection="driver={MySQL ODBC 3.51 Driver};server=server;uid=username;" \ & "pwd=password;database=database;stmt=SET NAMES 'big5';"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open strConnection
%>

同様に、Connector/Net で latin1 以外の文字セットを使用している場合は、接続文字列に文字セットを指定する必要があります。詳細は、Connecting to MySQL Using Connector/Netを参照してください。

PHP を使用している場合は、次のコードを試してください。

<?php $link = mysql_connect($host, $usr, $pwd); mysql_select_db($db); if( mysql_error() ) { print "Database ERROR: " . mysql_error(); } mysql_query("SET NAMES 'utf8'", $link);
?>

この場合、SET NAMES を使用して character_set_clientcharacter_set_connection、および character_set_results を変更しています。

mysql ではなく、新しい mysqli 拡張を使用することをお勧めします。mysqli を使用する場合は、前の例を次のように書き直すことができます。

<?php $link = new mysqli($host, $usr, $pwd, $db); if( mysqli_connect_errno() ) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $link->query("SET NAMES 'utf8'");
?>

PHP アプリケーションで頻繁に発生する別の問題は、ブラウザによって行われる想定に関連しています。<meta> タグを追加または変更するだけでこの問題が修正されることがあります。たとえば、ユーザーエージェントがページの内容を UTF-8 として解釈するようにするには、HTML ページの <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> を含めてください。

Connector/J を使用している場合は、Using Character Sets and Unicodeを参照してください。

A.11.10.

MySQL 5.6 にアップグレードしました。文字セットに関して、MySQL 4.0 の動作に戻すにはどうすればよいですか。

MySQL バージョン 4.0 では、サーバーおよびクライアントの両方のための単一のグローバル文字セットがあり、使用する文字の決定はサーバー管理者が行なっていました。これは MySQL バージョン 4.1 以降で変更されました。現在行われるのは、セクション10.1.4「接続文字セットおよび照合順序」に説明されているように、ハンドシェイクです。

クライアントが接続するときに、使用する文字セットの名前をサーバーに送信します。サーバーはこの名前を使用して、character_set_clientcharacter_set_results、および character_set_connection システム変数を設定します。実際には、サーバーは文字セット名を使用して SET NAMES 操作を実行します。

このことの影響は、--character-set-server=utf8 を指定して mysqld を開始することによって、クライアントの文字セットを制御できないことです。ただし、アジア地域には MySQL 4.0 の動作が望ましいという顧客がいます。この動作を維持できるように、--skip-character-set-client-handshake を使用してオフにできる mysqld スイッチ --character-set-client-handshake が追加されました。--skip-character-set-client-handshake を指定して mysqld を起動すると、クライアントが接続するときに、使用する文字セットの名前がサーバーに送信されますが、サーバーはクライアントからのこの要求を無視します

例として、望ましいサーバーの文字セットが latin1 であるとします (CJK 地域ではあまりないことですが、これはデフォルト値です)。クライアントのオペレーティングシステムでサポートされている文字セットであるため、クライアントが utf8 を使用しているとします。latin1 をデフォルトの文字セットとしてサーバーを起動します。

mysqld --character-set-server=latin1

そのあと、クライアントをデフォルトの文字セット utf8 で起動します。

mysql --default-character-set=utf8

現在の設定は、SHOW VARIABLES の出力を表示することによって確認できます。

mysql> SHOW VARIABLES LIKE 'char%';+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
8 rows in set (0.01 sec)

クライアントを停止し、mysqladmin を使用してサーバーを停止します。今度はハンドシェイクをスキップするように通知して、サーバーをふたたび起動します。

mysqld --character-set-server=utf8 --skip-character-set-client-handshake

クライアントをデフォルトの文字セットとして utf8 をふたたび指定して起動し、現在の設定を表示します。

mysql> SHOW VARIABLES LIKE 'char%';+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
8 rows in set (0.01 sec)

SHOW VARIABLES の異なる結果を比較することによって確認できるように、--skip-character-set-client-handshake が使用された場合、サーバーはクライアントの初期設定を無視します。

A.11.11.

CJK 文字での LIKE 検索および FULLTEXT 検索が失敗することがあるのはなぜですか。

BINARY カラムおよび BLOB カラムに対する LIKE 検索には非常に単純な問題があります。文字の終わりを判別する必要があることです。マルチバイト文字セットでは、各文字のオクテット長が異なることがあります。たとえば、utf8 の場合、次に示すように A は 1 バイトを必要としますが、 は 3 バイトを必要とします。

+-------------------------+---------------------------+
| OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |
+-------------------------+---------------------------+
| 1 | 3 |
+-------------------------+---------------------------+
1 row in set (0.00 sec)

最初の文字の終わりを判別できなければ、2 番目の文字が始まる位置を判別できません。この場合、LIKE '_A%' などの非常に単純な検索が失敗します。解決策は、通常の CJK 文字セットを最初から使用するか、比較する前に CJK 文字を変換することです。

これは、存在しない文字のエンコードを MySQL が許可できない理由の 1 つです。不正な入力を厳密に拒否しなければ、文字の終わりを判別する方法がありません。

FULLTEXT 検索の場合は、単語の始まりと終わりを判別する必要があります。西洋の言語の場合、それらのほとんど (すべてでなければ) が簡単に識別できる単語の境界 (スペース文字) を使用しているため、これが問題となることはほとんどありません。ただし、通常、アジアの言語ではこれは異なります。独自の判断で不完全な方法を使用して、すべての漢字が単語を表すと想定したり、(日本語の場合) 文法的な終わりに従ったカタカナからひらがなへの変化に応じるようにしたりすることもできます。ただし、唯一の確実な解決策では、包括的な単語のリストが必要となります。これは、サポートされる各アジア言語のサーバーに辞書を含める必要があることを意味します。これは簡単に言って実現可能ではありません。

A.11.12.

文字 X がすべての文字セットで使用可能であるかどうかを判別するにはどうすればよいですか。

簡体字中国語および半角ではない基本的な日本語のかな文字のほとんどは、すべての CJK 文字セットで表示されます。次のストアドプロシージャーは、UCS-2 Unicode 文字を受け入れて、それをほかのすべての文字セットに変換し、結果を 16 進数で表示します。

DELIMITER //
CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2)
BEGIN
CREATE TABLE tj (ucs2 CHAR(1) character set ucs2, utf8 CHAR(1) character set utf8, big5 CHAR(1) character set big5, cp932 CHAR(1) character set cp932, eucjpms CHAR(1) character set eucjpms, euckr CHAR(1) character set euckr, gb2312 CHAR(1) character set gb2312, gbk CHAR(1) character set gbk, sjis CHAR(1) character set sjis, ujis CHAR(1) character set ujis);
INSERT INTO tj (ucs2) VALUES (ucs2_char);
UPDATE tj SET utf8=ucs2, big5=ucs2, cp932=ucs2, eucjpms=ucs2, euckr=ucs2, gb2312=ucs2, gbk=ucs2, sjis=ucs2, ujis=ucs2;
SELECT hex(ucs2) AS ucs2, hex(utf8) AS utf8, hex(big5) AS big5, hex(cp932) AS cp932, hex(eucjpms) AS eucjpms, hex(euckr) AS euckr, hex(gb2312) AS gb2312, hex(gbk) AS gbk, hex(sjis) AS sjis, hex(ujis) AS ujis
FROM tj;
DROP TABLE tj;
END//

入力は、単一の ucs2 文字、またはその文字のコードポイント値 (16 進表記) です。たとえば、ucs2 のエンコードおよび名前についての Unicode のリスト (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt) から、カタカナ文字 Pe はすべての CJK 文字セットにあり、コードポイント値が 0x30da であることがわかります。この値を p_convert() の引数として使用すると、次のような結果となります。

mysql> CALL p_convert(0x30da)//+------+--------+------+-------+---------+-------+--------+------+------+------+
| ucs2 | utf8 | big5 | cp932 | eucjpms | euckr | gb2312 | gbk | sjis | ujis |
+------+--------+------+-------+---------+-------+--------+------+------+------+
| 30DA | E3839A | C772 | 8379 | A5DA | ABDA | A5DA | A5DA | 8379 | A5DA |
+------+--------+------+-------+---------+-------+--------+------+------+------+
1 row in set (0.04 sec)

カラム値が 3F (つまり、疑問符文字 (?)) であるカラムがないため、すべての変換が正常に行われたことがわかります。

A.11.13.

CJK 文字列が Unicode で間違ってソートされるのはなぜですか。(I)

utf8_unicode_ci 検索や ucs2_unicode_ci 検索、または ORDER BY ソートの結果が、母国語のユーザーが予期する結果ではないことがあります。バグである可能性を除外するわけではありませんが、多くのユーザーは Unicode Collation Algorithm の標準表のウェイトを正しく読んでいないことが過去に判明しました。MySQL は http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt にある表を使用しています。これは、unicode.org のホームページからナビゲートすることによって見つかる最初の表ではありません。MySQL はより新しい 4.1.0 の allkeys 表ではなく、古い 4.0.0 の表を使用しているためです。(MySQL 5.6 の新しい '520' 照合順序では、5.2 の allkeys 表が使用されています。)これは、次に示した Bug #16526 で報告されたような状況が発生しないように、インデックスに影響する順序付けの変更に非常に慎重であるためです。

mysql< CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci);Query OK, 0 rows affected (0.05 sec)
mysql> INSERT INTO tj VALUES ('が'),('か');Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM tj WHERE s1 = 'か';+------+
| s1 |
+------+
| が |
| か |
+------+
2 rows in set (0.00 sec)

最初の結果行の文字は、検索した文字ではありません。MySQL でその文字が取得されたのはなぜでしょうか。まず、Unicode のコードポイント値を確認します。これを行うには、ucs2 バージョンの文字の 16 進数を表示します。

mysql> SELECT s1, HEX(CONVERT(s1 USING ucs2)) FROM tj;+------+-----------------------------+
| s1 | HEX(CONVERT(s1 USING ucs2)) |
+------+-----------------------------+
| が | 304C |
| か | 304B |
+------+-----------------------------+
2 rows in set (0.03 sec)

4.0.0 allkeys 表で 304B および 304C を探すと、これらの行が見つかります。

304B ; [.1E57.0020.000E.304B] # HIRAGANA LETTER KA
304C ; [.1E57.0020.000E.304B][.0000.0140.0002.3099] # HIRAGANA LETTER GA; QQCM

正式な Unicode 名 (# マークの後ろにあります) は、日本語の五十音 (ひらがな)、非公式な区分 (文字、数字、または句読点)、西洋言語での識別子 (KA または GA。これは、たまたま同じ文字のペアの有声音および無声音となっています) を示しています。さらに重要なのは、プライマリウェイト (角括弧の中の最初の 16 進数) が両方の行で 1E57 となっていることです。検索とソートの両方の比較で、MySQL はプライマリウェイトのみに注意を払って、ほかのすべての数値を無視します。これは、「が」および「か」が Unicode の仕様に従って正しくソートされていることを意味します。これらを区別するには、UCA (Unicode Collation Algorithm) 以外の照合順序 (utf8_bin または utf8_general_ci) を使用するか、HEX() 値を比較するか、ORDER BY CONVERT(s1 USING sjis) を使用する必要があります。もちろん、Unicode に従えば正しいだけでは十分ではなく、バグを報告したユーザーも同様に正しいと言えます。KA/GA のような有声音/無声音文字のペアを順序付けのために区別できる、JIS X 4061 標準に従った別の日本語の照合順序を追加する計画があります。

A.11.14.

CJK 文字列が Unicode で間違ってソートされるのはなぜですか。(II)

Unicode (ucs2 または utf8) を使用していて、Unicode のソート順がわかっているが (セクションA.11「MySQL 5.6 FAQ: MySQL の中国語、日本語、および韓国語の文字セット」を参照してください)、MySQL でテーブルが間違ってソートされているように見える場合は、まずテーブルの文字セットを確認してください。

mysql> SHOW CREATE TABLE t\G******************** 1. row ******************
Table: t
Create Table: CREATE TABLE `t` (
`s1` char(1) CHARACTER SET ucs2 DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

文字セットは正しいように見えるため、このカラムに関して INFORMATION_SCHEMA.COLUMNS テーブルで表示できる情報を確認します。

mysql> SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME -> FROM INFORMATION_SCHEMA.COLUMNS -> WHERE COLUMN_NAME = 's1' -> AND TABLE_NAME = 't';+-------------+--------------------+-----------------+
| COLUMN_NAME | CHARACTER_SET_NAME | COLLATION_NAME |
+-------------+--------------------+-----------------+
| s1 | ucs2 | ucs2_general_ci |
+-------------+--------------------+-----------------+
1 row in set (0.01 sec)

(詳細は、セクション21.4「INFORMATION_SCHEMA COLUMNS テーブル」を参照してください。)

照合順序が ucs2_unicode_ci ではなく ucs2_general_ci であることがわかります。このようになる理由は、次のように SHOW CHARSET を使用して見つけることができます。

mysql> SHOW CHARSET LIKE 'ucs2%';+---------+---------------+-------------------+--------+
| Charset | Description | Default collation | Maxlen |
+---------+---------------+-------------------+--------+
| ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 |
+---------+---------------+-------------------+--------+
1 row in set (0.00 sec)

ucs2 および utf8 の場合、デフォルトの照合順序は general です。Unicode の照合順序を指定するには、COLLATE ucs2_unicode_ci を使用します。

A.11.15.

補助文字が MySQL で拒否されるのはなぜですか。

MySQL 5.5.3 より前では、MySQL は補助文字 (つまり、UTF-8 で 3 バイトを超えるサイズを必要とする文字) をサポートしていません。Unicode で基本多言語面/第 0 面と呼ばれているもののみがサポートされます。いくつかの非常に珍しい漢字のみが補助文字となっています。それらに対するサポートは一般的ではありません。このことが Bug #12600 などで報告され、バグではありませんとして拒否されました。utf8 では、理解できないバイトが出現した場合に、入力文字列を切り捨てる必要があります。そうしないと、不正なマルチバイト文字の長さがわかりません。

考えられる 1 つの回避策は、utf8 の代わりに ucs2 を使用することです。この場合、不正な文字は疑問符に置き換えられますが、切り捨ては行われません。妥当性チェックが行われない BLOB または BINARY にデータ型を変更することもできます。

MySQL 5.5.3 の時点では、追加の Unicode 文字セット utf16utf32、および 4 バイトの utf8mb4 によって Unicode のサポートが拡張され、補助文字が含まれるようになりました。これらの文字セットでは、基本多言語面 (BMP) の外にある補助 Unicode 文字がサポートされます。

A.11.16.

CJKVにするべきではありませんか。

いいえ。用語CJKV(Chinese Japanese Korean Vietnamese) は漢字 (もともとは中国語) が含まれているベトナム文字セットを指しています。MySQL では、漢字を使用した古いベトナム文字をサポートする計画はありません。MySQL では、西洋文字を使用する現代のベトナム文字はもちろんサポートされます。

MySQL 5.6 の時点では、セクション10.1.14.1「Unicode 文字セット」で説明しているように、Unicode 文字セットにベトナム語の照合順序があります。

A.11.17.

MySQL では CJK 文字をデータベース名およびテーブル名に使用できますか。

この問題は、対応するディレクトリおよびファイルの名前を自動的に書き換えることによって、MySQL 5.1 で修正されました。

たとえば、オペレーティングシステムでディレクトリ名に CJK がサポートされないサーバーに「楮」という名前のデータベースを作成した場合、MySQL は E6A5AE (つまり、「楮」文字の Unicode の 16 進表現) を特殊な方法でエンコードした @0w@00a5@00ae という名前のディレクトリが作成されます。ただし、SHOW DATABASES ステートメントを実行すると、データベースが「楮」として示されます。

A.11.18.

MySQL マニュアルの中国語版、日本語版、および韓国語版はどこにありますか。

MySQL 5.1.12 の簡体字中国語版のマニュアルは、http://dev.mysql.com/doc/にあります。MySQL 4.1 マニュアルの日本語版は、http://dev.mysql.com/doc/ からダウンロードできます。

A.11.19.

MySQL での CJK および関連する問題についての支援はどこで受けることができますか。

次のリソースを利用できます。

A.12 MySQL 5.6 FAQ: コネクタおよび API

MySQL Connector およびその他の API に関する一般的な質問、問題、および回答については、マニュアルの次の部分を参照してください。

A.13 MySQL 5.6 FAQ: レプリケーション

次のセクションでは、MySQL レプリケーションに関するよくある質問に回答しています。

A.13.1. スレーブはマスターに常時接続されている必要がありますか。
A.13.2. レプリケーションを有効にするには、マスターとスレーブのネットワーク接続を有効にする必要がありますか。
A.13.3. マスターと比較してスレーブがどれくらい遅れているかを判別するにはどのようにすればよいですか。言い換えると、スレーブによってレプリケートされた最後のステートメントの日付はどのように判別できますか。
A.13.4. スレーブが追いつくまで、マスターで更新をブロックするにはどうすればよいですか。
A.13.5. 二方向レプリケーションを設定する場合に注意する問題はありますか。
A.13.6. レプリケーションを使用してシステムのパフォーマンスを改善するにはどうすればよいですか。
A.13.7. パフォーマンスがより高いレプリケーションを使用するには、アプリケーションのクライアントコードを準備するときに何を行えばよいですか。
A.13.8. MySQL レプリケーションによってシステムのパフォーマンスが向上するのは、どのような場合でどの程度向上しますか。
A.13.9. 冗長性または高可用性を持たせるには、レプリケーションをどのように使用すればよいですか。
A.13.10. マスターサーバーがステートメントベースのバイナリロギング形式または行ベースのバイナリロギング形式のどちらを使用しているかを判別するにはどうすればよいですか。
A.13.11. 行ベースのレプリケーションを使用するようにスレーブに指示するにはどうすればよいですか。
A.13.12. GRANT ステートメントおよび REVOKE ステートメントがスレーブマシンにレプリケートされないようにするにはどうすればよいですか。
A.13.13. オペレーティングシステムが混在している場合、レプリケーションは動作しますか (たとえば、マスターは Linux で実行され、スレーブは OS X および Windows で実行されている場合)。
A.13.14. ハードウェアのアーキテクチャーが混在している場合、レプリケーションは動作しますか (たとえば、マスターは 64 ビットマシンで実行され、スレーブは 32 ビットマシンで実行されている場合)。

A.13.1.

スレーブはマスターに常時接続されている必要がありますか。

いいえ、その必要はありません。スレーブは、シャットダウンされるか、数時間または数日間切断されても、再接続してマスターの更新に追いつくことができます。たとえば、リンクが散発的に短時間接続されるダイヤルアップリンクを使用して、マスターとスレーブの関係を設定できます。これは、特殊な対応が行われていないかぎり、特定の時点でスレーブがマスターと同期されていることは保証されないことを意味します。

切断されているスレーブが追いつくことができるようにするには、スレーブにまだレプリケートされていない情報が含まれているマスターからのバイナリログファイルを削除しないでください。非同期レプリケーションは、スレーブが最後にイベントを読み取った位置からバイナリログを継続して読み取ることができる場合にのみ動作できます。

A.13.2.

レプリケーションを有効にするには、マスターとスレーブのネットワーク接続を有効にする必要がありますか。

はい。マスターとスレーブのネットワーク接続を有効にする必要があります。ネットワーク接続を有効にしないと、スレーブはマスターに接続できず、バイナリログを転送できません。両方のサーバーの構成ファイルで skip-networking オプションが有効にされていないことを確認します。

A.13.3.

マスターと比較してスレーブがどれくらい遅れているかを判別するにはどのようにすればよいですか。言い換えると、スレーブによってレプリケートされた最後のステートメントの日付はどのように判別できますか。

SHOW SLAVE STATUS の出力の Seconds_Behind_Master カラムを確認してください。セクション17.1.5.1「レプリケーションステータスの確認」を参照してください。

スレーブの SQL スレッドでマスターから読み取ったイベントを実行するときに、このスレッドは実行時の時間をイベントのタイムスタンプに変更します。(これにより、TIMESTAMP が正常にレプリケートされます。)SHOW PROCESSLIST の出力で、スレーブの SQL スレッドの Time カラムに表示される秒数は、最後にレプリケートされたイベントのタイムスタンプとスレーブマシンの実際の時間の差異の秒数です。これを使用して、最後にレプリケートされたイベントの日付を判別できます。スレーブがマスターから切断されて 1 時間たってから再接続された直後の場合は、SHOW PROCESSLIST のスレーブ SQL スレッドに大きい Time 値 (3600 など) が表示されることがあります。これは、スレーブが 1 時間前のステートメントを実行しているためです。セクション17.2.1「レプリケーション実装の詳細」を参照してください。

A.13.4.

スレーブが追いつくまで、マスターで更新をブロックするにはどうすればよいですか。

次の手順を使用します。

  1. マスターで次のステートメントを実行します。

    mysql> FLUSH TABLES WITH READ LOCK;mysql> SHOW MASTER STATUS;

    SHOW ステートメントの出力から、レプリケーション座標 (現在のバイナリログファイル名および位置) を記録します。

  2. スレーブで次のステートメントを発行します。ここで、MASTER_POS_WAIT() 関数への引数は、前のステップで取得したレプリケーション座標値です。

    mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);

    この SELECT ステートメントは、スレーブが指定されたログファイルおよび位置に達するまで更新をブロックします。その時点で、スレーブがマスターと同期され、ステートメントが戻ります。

  3. マスターで次のステートメントを発行して、更新処理がマスターでふたたび開始されるようにします。

    mysql> UNLOCK TABLES;

A.13.5.

二方向レプリケーションを設定する場合に注意する問題はありますか。

現在、MySQL レプリケーションでは、分散 (サーバー間) 更新の原子性を保証するためのマスターおよびスレーブ間のロックプロトコルはサポートされていません。言い換えると、クライアント A が co-master 1 を更新し、それを co-master 2 に伝播する前にクライアント B が co-master 2 を更新した場合、クライアント A の更新が co-master 1 への更新と異なる更新になる可能性があります。このため、クライアント A の更新が co-master 2 に行われたときに、co-master 2 からの更新がすべて伝播されたあとでも、co-master 1 とは異なるテーブルとなります。これは、どのような順序でも更新が安全に行われるという確証がある場合、またはクライアントコードで更新順序の間違いに対処できる場合を除いて、2 つのサーバーを二方向レプリケーション関係にするべきではないことを意味します。

二方向レプリケーションでは、実際には、更新に関してパフォーマンスはそれほど向上しません。各サーバーは、単一のサーバーで更新を行うときと同量の更新を行う必要があります。唯一の違いは、別のサーバーで発生した更新が 1 つのスレーブスレッドに直列化されるため、ロック競合がやや少ないことです。この利点さえも、ネットワーク遅延によって相殺されてしまうことがあります。

A.13.6.

レプリケーションを使用してシステムのパフォーマンスを改善するにはどうすればよいですか。

1 つのサーバーをマスターとして設定し、すべての書き込みをそれに指示します。そして、予算とラックスペースが許すかぎり多くのスレーブを構成し、マスターと複数のスレーブに読み取りを分散します。スレーブ側の速度を改善するには、--skip-innodb--low-priority-updates、および --delay-key-write=ALL オプションを指定してスレーブを起動することもできます。この場合、スレーブは InnoDB テーブルの代わりに非トランザクションの MyISAM テーブルを使用し、トランザクションのオーバーヘッドを排除して速度を上げます。

A.13.7.

パフォーマンスがより高いレプリケーションを使用するには、アプリケーションのクライアントコードを準備するときに何を行えばよいですか。

スケールアウトソリューションとしてレプリケーションを使用するためのガイドについては、セクション17.3.3「スケールアウトのためにレプリケーションを使用する」を参照してください。

A.13.8.

MySQL レプリケーションによってシステムのパフォーマンスが向上するのは、どのような場合でどの程度向上しますか。

MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどないシステムにもっとも適しています。理論的には、単一のマスターおよび複数のスレーブのセットアップを使用する場合、ネットワーク帯域幅がなくなるか、マスターで更新のロードを処理できないポイントに到達するまでは、スレーブを追加することによってシステムを拡張できます。

処理能力の上積みが横ばいになる前のスレーブの数、およびサイトのパフォーマンスを改善できる度合いを判別するには、クエリーパターンを知り、典型的なマスターおよび典型的なスレーブでの読み取りおよび書き込みのスループットの関係をベンチマークすることによって経験的に判別する必要があります。ここでは、架空のシステムのレプリケーションの構成を単純に計算した例を示します。reads および writes は、1 秒当たりの読み取りおよび書き込みの数をそれぞれ示しています。

システムのロードは 10% の書き込みと 90% の読み取りで構成されていて、ベンチマークによって reads が 1200 - 2 * writes であることが判別されたとします。つまり、書き込みがない場合、システムは毎秒 1,200 回の読み取りを実行できます。書き込みの平均は読み取りの平均の 2 倍の時間がかかり、この関係はリニア (直線的) です。マスターと各スレーブの容量は同じであり、1 つのマスターと N 個のスレーブがあるとします。この場合、各サーバー (マスターまたはスレーブ) は次のようになります。

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (読み取りは分散されますが、書き込みはすべてのスレーブにレプリケートされます)

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

最後の等式は、実行可能な最大読み取り回数が毎秒 1200 回で、書き込み 1 回当たり 9 回の読み取りがある場合の N 個のスレーブの書き込みの最大数を示しています。

この分析によって、次の結論が導かれます。

  • N = 0 (レプリケーションがないことを意味します) の場合、システムは毎秒 1200/11 = 109 回の書き込みを処理できます。

  • N = 1 の場合、毎秒最大 184 回の書き込みを実行できます。

  • N = 8 の場合、毎秒最大 400 回の書き込みを実行できます。

  • N = 17 の場合、毎秒最大 480 回の書き込みを実行できます。

  • N が無限に近づくと (予算も負の無限大になり)、毎秒 600 回の書き込みに近くなり、システムスループットは 5.5 倍になります。ただし、8 サーバーのみでも 4 倍近くに増えます。

これらの計算ではネットワーク帯域幅を無限と想定しており、システムにおいて重要である可能性があるさまざまなほかの要因が無視されています。多くの場合、N 個のレプリケーションスレーブを追加した場合のシステムの状態を正確に予測する前述と同様の計算を行うことはできません。ただし、次の質問に答えると、レプリケーションによってシステムのパフォーマンスが改善されるかどうか、およびどれくらい改善されるかを判別するのに役立ちます。

  • システムの読み取りと書き込みの比率はどれくらいですか。

  • 読み取りを減らした場合、単一のサーバーで書き込みのロードをどれくらい処理できますか。

  • ネットワークで帯域幅を使用できるスレーブはいくつですか。

A.13.9.

冗長性または高可用性を持たせるには、レプリケーションをどのように使用すればよいですか。

冗長性の実装方法は、アプリケーションおよび状況によってまったく異なります。高可用性ソリューション (自動フェイルオーバーを使用する) では、アクティブなモニタリング、および元の MySQL サーバーからスレーブへのフェイルオーバーのサポートを提供する、カスタムスクリプトまたはサードパーティーのツールが必要となります。

この処理を手動で行うには、新しいサーバーとやり取りするようにアプリケーションを変更するか、MySQL サーバーの DNS を障害が発生したサーバーから新しいサーバーに変更することによって、障害が発生したマスターから事前構成されているスレーブに切り替えることができる必要があります。

詳細およびソリューションの例については、セクション17.3.6「フェイルオーバー中にマスターを切り替える」を参照してください。

A.13.10.

マスターサーバーがステートメントベースのバイナリロギング形式または行ベースのバイナリロギング形式のどちらを使用しているかを判別するにはどうすればよいですか。

binlog_format システム変数の値を確認します。

mysql> SHOW VARIABLES LIKE 'binlog_format';

表示される値は、STATEMENTROW、または MIXED のいずれかです。MIXED モードの場合、行ベースのロギングが望ましいのですが、特定の状況では、レプリケーションがステートメントベースのロギングに自動的に切り替わります。これが発生する場合については、セクション5.2.4.3「混合形式のバイナリロギング形式」を参照してください。

A.13.11.

行ベースのレプリケーションを使用するようにスレーブに指示するにはどうすればよいですか。

スレーブは使用する形式を自動的に識別します。

A.13.12.

GRANT ステートメントおよび REVOKE ステートメントがスレーブマシンにレプリケートされないようにするにはどうすればよいですか。

--replicate-wild-ignore-table=mysql.% オプションを指定してサーバーを起動し、mysql データベースのテーブルのレプリケーションが無視されるようにします。

A.13.13.

オペレーティングシステムが混在している場合、レプリケーションは動作しますか (たとえば、マスターは Linux で実行され、スレーブは OS X および Windows で実行されている場合)。

はい。

A.13.14.

ハードウェアのアーキテクチャーが混在している場合、レプリケーションは動作しますか (たとえば、マスターは 64 ビットマシンで実行され、スレーブは 32 ビットマシンで実行されている場合)。

はい。

A.14 MySQL 5.6 FAQ: MySQL エンタープライズスケーラビリティースレッドプール

A.14.1. スレッドプールとは何ですか。これはどのような問題を解決しますか。
A.14.2. スレッドプールは、最適なパフォーマンスおよびスループットのために、並列セッションおよびトランザクションをどのように制限および管理しますか。
A.14.3. スレッドプールは、クライアント側の接続プールとどのように異なりますか。
A.14.4. スレッドプールはどのような場合に使用しますか。
A.14.5. 推奨されるスレッドプールの構成はありますか。

A.14.1.

スレッドプールとは何ですか。これはどのような問題を解決しますか。

MySQL スレッドプールは、MySQL サーバーのデフォルトの接続処理機能を拡張する MySQL サーバーのプラグインであり、ステートメント/クエリーおよびトランザクションの並列実行数を制限して、タスクを完了するための CPU およびメモリーのリソースがそれぞれに十分に確保されるようにします。MySQL 5.5 および 5.6 の商用配布には、スレッドプールプラグインが含まれています。

MySQL サーバーのデフォルトのスレッド処理モデルでは、クライアント接続ごとに 1 つのスレッドを使用してステートメントが実行されます。より多くのクライアントがサーバーに接続してステートメントを実行すると、全体的なパフォーマンスが低下します。スレッドプールプラグインは、オーバーヘッドを軽減してパフォーマンスを向上させるように設計された代替のスレッド処理モデルを提供します。スレッドプールプラグインは、特に現在のマルチ CPU/コアシステムでの多数のクライアント接続において、ステートメント実行スレッドを効率的に管理することによって、サーバーのパフォーマンスを向上させます。

詳細は、セクション8.11.6「スレッドプールプラグイン」を参照してください。

A.14.2.

スレッドプールは、最適なパフォーマンスおよびスループットのために、並列セッションおよびトランザクションをどのように制限および管理しますか。

スレッドプールは、分割統治手法を使用して並列性を制限および調整します。MySQL サーバーのデフォルトの接続処理と異なり、スレッドプールでは接続とスレッドが分離され、接続およびそれらの接続から受け取ったステートメントを実行するスレッドが固定された関係を持たないようになっています。スレッドプールは、構成可能なスレッドグループ内でクライアント接続を管理します。スレッドグループでは、実行される処理の性質に基づいて優先順位が付けられ、キューに入れられます。

詳細は、セクション8.11.6.2「スレッドプール操作」を参照してください。

A.14.3.

スレッドプールは、クライアント側の接続プールとどのように異なりますか。

MySQL 接続プールはクライアント側で動作し、MySQL サーバーに対して MySQL クライアントで接続および切断が繰り返されないようにします。MySQL クライアントのアイドル状態の接続をキャッシュし、必要に応じてほかのユーザーが使用できるように設計されています。これにより、クエリーが MySQL サーバーに発行されたときに、接続の確立および切断のオーバーヘッドおよびコストが最小化されます。MySQL 接続プールは、クエリー処理機能、またはバックエンドの MySQL サーバーの負荷を認識できません。それとは対照的に、スレッドプールは MySQL サーバー側で動作し、インバウンドの並列接続の実行、およびバックエンドの MySQL データベースにアクセスするクライアント接続から受け取ったクエリーの実行を管理するように設計されています。機能が分離されているため、MySQL 接続プールとスレッドプールは次元の異なるものであり、相互に独立して使用できます。

MySQL Connector を使用した MySQL の接続プールについては、第23章「Connector および APIで説明しています。

A.14.4.

スレッドプールはどのような場合に使用しますか。

スレッドプールを最適に使用するには、考慮するべきいくつかの経験則があります。

MySQL の Threads_running 変数は、MySQL サーバーで現在実行されている並列ステートメントの数を追跡します。この変数がサーバーが最適に動作しない範囲に常時ある場合 (通常、InnoDB のワークロードの場合、40 を超えている場合)、特にきわめて並列負荷が高い状況では、スレッドプールを使用することは効果があります。

innodb_thread_concurrency を使用して同時に実行されるステートメントの数を制限している場合、スレッドプールを使用すると、トランザクションの内容、ユーザー定義の指定などに基づいて、接続をスレッドグループに割り当てて実行をキューに入れることによって、同じ問題が少しだけ良好に解決されます。

最後に、ワークロードが主に短いクエリーで構成されている場合、スレッドプールを使用することは効果があります。

詳細は、セクション8.11.6.3「スレッドプールのチューニング」を参照してください。

A.14.5.

推奨されるスレッドプールの構成はありますか。

スレッドプールには、パフォーマンスに影響する、ユーザー事例から追加された多数の構成パラメータがあります。これらの詳細、およびチューニングのヒントについては、セクション8.11.6.3「スレッドプールのチューニング」を参照してください。

関連キーワード:  A,ノード,サーバー,テーブル,セクション,サポート,スレーブ,データ,セット,ステートメント