第4章 データベース管理

目次

4.1. サーバ サイド プログラムの概略
4.2. mysqld ? MySQL サーバ
4.2.1. オプションと変数のリファレンス
4.2.2. コマンド オプション
4.2.3. システム変数
4.2.4. システム変数の使用
4.2.5. ステータス変数
4.2.6. SQL モード
4.2.7. シャットダウン プロセス
4.2.8. サーバ サイド ヘルプ
4.3. MySQL サーバ スタートアップ プログラム
4.3.1. mysqld_safe ? MySQL サーバ スタートアップ スクリプト
4.3.2. mysql.server ? MySQL サーバ スタートアップ スクリプト
4.3.3. mysqld_multi ? 複数のMySQL サーバ管理
4.4. mysqlmanager ? MySQL Instance Manager
4.4.1. MySQL Instance Manager コマンド オプション
4.4.2. MySQL Instance Manager の設定ファイル
4.4.3. MySQL Instance Manager で MySQL Server の起動
4.4.4. Instance Manager のユーザとパスワード管理
4.4.5. MySQL サーバ インスタンス ステータスの監視
4.4.6. MySQL Instance Manager へ接続
4.4.7. MySQL Instance Manager のコマンド
4.5. インストール関連プログラム
4.5.1. make_win_bin_dist ? Package MySQL 配布 (ZIP アーカイブ)
4.5.2. mysql_fix_privilege_tables ? MySQL システム テーブルのアップグレード
4.5.3. mysql_install_db ? MySQL データ ディレクトリ 初期化スクリプト
4.5.4. mysql_upgrade ? MySQL アップグレードのテーブル チェック
4.5.5. mysql_tzinfo_to_sql ? タイム ゾーン テーブルのロード
4.6. セキュリティ問題
4.6.1. セキュリティ ガイドライン
4.6.2. MySQL のクラッカー対策
4.6.3. セキュリティ関連の mysqld オプション
4.6.4. LOAD DATA LOCAL のセキュリティ関連事項
4.6.5. ユーザによる MySQL の実行
4.7. MySQL アクセス権限システム
4.7.1. 権限システムの役割
4.7.2. 権限システムの機能
4.7.3. MySQL 提供の権限
4.7.4. MySQL サーバへの接続
4.7.5. アクセス制御の段階 1: 接続確認
4.7.6. アクセス制御の段階 2: 接続確認
4.7.7. 権限の変更が反映するタイミング
4.7.8. Access denied エラーの原因
4.7.9. MySQL 4.1 のパスワードハッシュ
4.8. MySQL ユーザ アカウント管理
4.8.1. MySQL ユーザ名とパスワード
4.8.2. MySQL への新規ユーザの追加
4.8.3. MySQL ユーザの削除
4.8.4. ユーザ リソースの制限
4.8.5. パスワードの設定
4.8.6. パスワードのセキュリティ
4.8.7. 接続安全
4.9. バックアップとリカバリ
4.9.1. データベースのバックアップ
4.9.2. バックアップとリカバリ手法の例示
4.9.3. 任意時点のリカバリ
4.9.4. テーブル保守とクラッシュ リカバリ
4.10. MySQL のローカライズと国際的使用
4.10.1. データおよびソート用キャラクタ セット
4.10.2. 英語以外のエラーメッセージ
4.10.3. 新しいキャラクタ セットの追加
4.10.4. キャラクタ定義配列
4.10.5. 文字列照合サポート
4.10.6. マルチ バイト文字サポート
4.10.7. キャラクタ セットに関する問題
4.10.8. MySQL サーバのタイム ゾーン サポート
4.10.9. MySQL サーバのローケル サポート
4.11. MySQL サーバ ログ
4.11.1. 一般クエリとスロー クエリのログ出力先の選択
4.11.2. エラー ログ
4.11.3. 一般クエリ ログ
4.11.4. バイナリ ログ
4.11.5. スロー クエリ ログ
4.11.6. ログ ファイルの保守
4.12. 同じマシン上での複数 MySQL サーバの実行
4.12.1. Windows で複数サーバの実行
4.12.2. Unix で複数サーバの実行
4.12.3. 複数サーバ環境でのクライアントプログラムの使用
4.13. MySQL クエリ キャッシュ
4.13.1. クエリ キャッシュの動作
4.13.2. クエリ キャッシュでの SELECT オプション
4.13.3. クエリ キャッシュの設定
4.13.4. クエリ キャッシュのステータスと保守

この章では、MySQLのインストールに関わる管理事項について説明します。

4.1. サーバ サイド プログラムの概略

MySQL サーバ、mysqld は、 MySQL 設定の中核を担うメイン プログラムです。このプログラムには、MySQL を設置するときの設定方法やサーバの起動と停止の関連スクリプトなどを添付しています。このセクションでは、サーバと関連プログラムの概要について説明します。次のセクションでは、そのプログラムに関する詳細について説明します。

MySQL プログラムには様々なオプションがあります。それぞれのプログラムには、プログラム オプションの詳細などを示す --help オプションがあります。必要に応じて、mysqld --help コマンドを試行してください。

MySQL の標準プログラム (デフォルト値) は、コマンドラインまたはオプション ファイルなどで指定して、書き換えることができます。詳細は、項3.3. 「プログラム・オプションの指定」 を参照してください。

次のリストは、MySQL サーバと関連プログラムの概説です。

サーバ ホストでは他のプログラムも稼動しています。

  • make_binary_distribution

    このプログラムでコンパイルした MySQLのバイナリ リリースを行う。これは、他の MySQL ユーザの便宜を図り、FTP を経由して ftp.mysql.com/pub/mysql/upload/ で送ることができる。

4.2. mysqld ? MySQL サーバ

mysqld は MySQL サーバです。ここでは、MySQL サーバ設定について説明します。

  • サーバ サポートの起動オプション

  • サーバのシステム変数

  • サーバ ステータス変数

  • SQL モードの設定方法

  • 停止プロセス

ノート:MySQL サーバのバイナリとコンフィギュレーションでは、すべてのストレージ エンジンはサポートしていません。使用している MySQL サーバでサポートがあるストレージ エンジンを確認するには、項12.5.4.13. 「SHOW ENGINES 構文」 を参照してください。

4.2.1. オプションと変数のリファレンス

次のテーブルに、mysqld 内で適用できるすべてのコマンド ライン オプション、サーバ、ステータス変数をリストします。

テーブルには、コマンド ライン オプション (Cmd-line)、設定ファイル のオプション (Option file)、サーバのシステム変数 (Server Var)、ステータス変数 (Status var) の一覧と、どのオプションや変数が利用可能であるかということも示しています。コマンドラインやオプション ファイルで設定するサーバ オプションが、対応するサーバ システムやステータス変数の名前と異なる場合には、そのオプションの下に変数名を記しています。ステータス変数に関しては、変数のスコープ (Scope) がグローバル、セッション、あるいはその両方です。それぞれのオプションと変数に関する詳細や設定方法は、それぞれのリンクを参照してください。

注意

現在、このテーブルの情報拡大または簡略化を行っています。テーブルに関する改善と追加情報に関しては、近日中の公開となります。

4.2.2. コマンド オプション

mysqld サーバを立ち上げるときに、項3.3. 「プログラム・オプションの指定」 で説明しているやり方で、プログラム オプションを指定します。オプション ファイルまたはコマンド ラインでオプションを使用することが、最も一般的な方法です。作業を開始する前に、オプション ファイルなどを利用して、実行ごとにサーバが常に同じオプションを使用していることを確認してください。詳細は 項3.3.2. 「オプションファイルの使用」 を参照してください。

mysqld[mysqld][server] のグループからオプションを読み込みます。mysqld_safe[mysqld][server][mysqld_safe][safe_mysqld] などのグループからオプションを読み込みます。mysql.server[mysqld][mysql.server] のグループからオプションを読み込みます。

Embedded MySQL サーバは通常、[server][embedded]、および [xxxxx_SERVER] からオプションを読み込みます。ここでは、xxxxx はこのサーバを組み込んでいるアプリケーション名です。

mysqld には、様々なコマンド オプションがあります。mysqld --help を実行すると概説を参照できます。完全なオプション一覧を参照するには、mysqld --verbose --help を実行してください。

次に、一般的なサーバ オプションについて説明します。別用途のオプションについては、別のセクションで説明します。

変数名をオプションに使用して、サーバのシステム変数の値を設定できます。これに関しては、このセクションで後述します。

  • --help, -?

    ショート ヘルプ メッセージを表示、終了。詳細メッセージを参照するには、--verbose--help オプションを使用する。

  • --allow-suspicious-udfs

    メイン関数が xxx というシンボル (名前) だけのユーザ定義関数をロードでするかどうかを制御する。デフォルトはオフ (無効) で、少なくとも一つの追加関数を持ったユーザ定義関数だけをロードできる。つまり、不正なユーザ定義関数をロードする危険性を防ぐ設定になっている。詳細は 項25.3.4.6. 「User-Defined Function Security Precautions」 を参照のこと。

  • --ansi

    MySQL 構文ではなく、ANSI 準拠の SQL 文を使用する。SQL モードの精密制御には、 --sql-mode オプションを使用する。詳細は 項1.8.3. 「ANSIモードでのMySQLの実行」 および 項4.2.6. 「SQL モード」 を参照のこと。

  • --basedir=path, -b path

    MySQLをインストールしているディレクトリへの基準パス。 パスは通常、このディレクトリに関係する。

  • big-tables

    すべてのテンポラリ セットをファイルに保存して、大きな結果セットにする。ほとんどの 「table full」 エラーがこのオプションで解決するが、メモリ内テーブルだけで足りるクエリの実行速度も遅くする。MySQL 3.23.2 以降、必要に応じて、小さいテンポラリ テーブルにメモリを使用し、大きな結果セットを自動的にディスク テーブルでの保存に切り替える。

  • --bind-address=IP

    バインドする IP アドレス。

  • --binlog-format={row|statement}

    レプリケーションに、レコード ベースとステートメント ベースのどちらを使用するかを指定する。詳細は 項5.1.2. 「レプリケーション フォーマット」 を参照のこと。(MySQL 5.1.5 からの導入)

  • --binlog-row-event-max-size=N

    行ベースのバイナリ ログ イベントの最大サイズ (バイト) を指定する。イベントにグループ化する行のサイズはこの値より小さいことが望ましい。値を256 の倍数とする。デフォルトは 1024。詳細は 項5.1.2. 「レプリケーション フォーマット」 を参照のこと。(MySQL 5.1.5 からの導入)

  • --bootstrap

    mysql_install_db スクリプト実行時に使用するオプション。 MySQL サーバを起動せずに MySQL 権限テーブルを作成できる。

    このオプションは、MySQL のコンフィギュレーションに --disable-grant-options オプションを使用していた場合は使えない。詳細は 項2.9.2. 「典型的な configure オプション」 を参照のこと。

  • --character-sets-dir=path

    キャラクタ セットを格納しているディレクトリ。詳細は 項4.10.1. 「データおよびソート用キャラクタ セット」 を参照のこと。

  • --character-set-client-handshake

    クライアント送信のキャラクタ セット情報を無視しない (ようにする) オプション。クライアント情報を無視して、サーバのデフォルトのキャラクタ セットを使用するには、--skip-character-set-client-handshake を使用する (MySQL が MySQL 4.0. のように動作するようにする。)

  • --character-set-filesystem=charset_name

    ファイルシステムのキャラクタ セット。character_set_filesystem のシステム変数を設定する。(MySQL 5.1.6. からの導入)

  • --character-set-server=charset_name, -C charset_name

    デフォルトのキャラクタ セットを設定するときに charset_name を使用する。詳細は 項4.10.1. 「データおよびソート用キャラクタ セット」 を参照のこと。このオプションを使用する場合には、非デフォルトのキャラクタ セットを指定する。照合順序は --collation-server で指定する。

  • --chroot=path

    MySQL サーバ起動中に chroot() のシステム コールを使用して、mysqld の Closed 環境でサーバを起動 (デーモンを配置)する。これは推奨セキィリティ対策。ただし、このオプションを使用すると LOAD DATA INFILESELECT ... INTO OUTFILE に制約が加わる。

  • --collation-server=collation_name

    サーバのデフォルトの照合順序を設定するときに collation_name を指定する。詳細は 項4.10.1. 「データおよびソート用キャラクタ セット」 を参照のこと。

  • --console

    --log-error を指定している場合でも、stderr および stdout にエラー ログ メッセージを書き込む。Windows のみに適用。このオプションを使用した場合、 mysqld で、コンソール画面を閉じない (開いたままになる)。

  • --core-file

    mysqld が異常終了した場合に、コア ファイルを作成する。システムによっては、mysqld_safe (mysqld のラッパ) に --core-file-size の指定が必要になる。詳細は 項4.3.1. 「mysqld_safe ? MySQL サーバ スタートアップ スクリプト」 を参照のこと。注意: --user オプションも使用している場合、Solaris などシステムではコア ファイルを作成できない。

  • --datadir=path, -h path

    データ ディレクトリへのパス

  • --debug[=debug_options], -# [debug_options]

    --with-debug でコンパイルした MySQL を使っている場合、このオプションを使用して mysqld のトレース ファイルを取得できる。debug_options の文字列は、'd:t:o,file_name' という並び (通常)。デフォルトは 'd:t:i:o,mysqld.trace'。詳細は Creating Trace Files を参照。

    MySQL 5.1.12 以降、デバッグ サポートに --with-debug を使用して MySQL をコンパイルすると、サーバ起動時に --debug="d,parser_debug" を使用できる。これは、SQL 文の処理に使用している Bison パーサーが、サーバの標準エラー出力にパーサー トレースをダンプすることを起因します。

  • --default-character-set=charset_name (DEPRECATED)

    デフォルトのキャラクタ セットを設定するときに、 charset_name を使用する。このオプションは --character-set-server をうけて、廃止予定である。詳細は 項4.10.1. 「データおよびソート用キャラクタ セット」 を参照のこと。

  • --default-collation=collation_name

    デフォルトの照合順序を設定するときに collation_name を使用する。このオプションは --collation-server をうけて、廃止予定である。詳細は 項4.10.1. 「データおよびソート用キャラクタ セット」 を参照のこと。

  • --default-storage-engine=type

    デフォルトのストーレジ エンジン (テーブル タイプ) を設定する。詳細は 章?13. ストレージエンジンとテーブルタイプ を参照のこと。

  • --default-table-type=type

    このオプションは、--default-storage-engine のシノニム (別名)。

  • --default-time-zone=timezone

    サーバのデフォルト タイム ゾーンを指定する。このオプションで、グローバル スコープの time_zone システム変数をセットする。このオプションを使用しない場合、デフォルトのタイム ゾーンは、システムのタイム ゾーンと同一になる。(system_time_zone システム変数の値)

  • --delay-key-write[={OFF|ON|ALL}]

    遅れたキーの書き込みをどうするかを指定する。キーの書き込みが遅れると、キー バッファを MyISAM テーブルへの書き込み間のフラッシュを抑制する。OFF で遅れたキーの書き込みを無効にする。ONDELAY_KEY_WRITE オプションで作成したテーブルに対して遅れたキーの書き込みを可能にする。ALL はすべての MyISAM テーブルに対するキー書き込みを遅らせる。詳細は 項6.5.2. 「サーバパラメータのチューニング」 および 項13.4.1. 「MyISAM スタートアップオプション」 を参照のこと。

    ノート:この変数を ALL にセットするときに、別のMySQL サーバ、または myisamchk コマンドなどテーブルが使用中の場合は、別のプログラム内から MyISAM デーブルを使用しないでください。インデックス破損の原因になります。

  • --des-key-file=file_name

    DES_ENCRYPT() および DES_DECRYPT() 関数で使用するデフォルトの DES キー をこのファイルから読み取る。

  • --enable-named-pipe

    名前付きパイプ (named pipe) のサポートを有効化する。これは Windows NT、2000、XP、2003 のみで使用可能。mysqld-nt または名前付きパイプの接続をサポートしているサーバで使用可能。

  • --event-scheduler

    イベント スケジューラを無効、有効、開始、停止するオプション (MySQL 5.1.6 からの導入) 注意: 許容値とその動作に関しては MySQL 5.1.11 で変更し、MySQL 5.1.12 でも再度変更している。

    詳細は event-scheduler オプション を参照のこと。

  • --exit-info[=flags], -T [flags]

    mysqld サーバのデバッグに使用できる、複数の異なるフラグのビット マスク。このオプションを 使用するには、完全に このオプションを理解していることが必要。

  • --external-locking

    外部ロック (システム ロック) を有効にする。MySQL 4.0 のデフォルトでは無効と設定していた。注意:lockd が完全には機能しないシステム (Linux など) でこのオプションを使用すると、簡単に mysqld がデッドロックになる。このオプションの旧称は --enable-locking

    ノート:MySQL のプロセスにおいて、MyISAM テーブルへの更新を有効にするためにこのオプションを使用する場合、次の条件を満たす必要がある。

    • 別のプロセスで更新したテーブルを使用するクエリをキャッシュしていない。

    • 共有テーブルで --delay-key-write=ALL または DELAY_KEY_WRITE=1 を使用していない。

    この条件を定かにする方法は、常に --external-locking--delay-key-write=OFF および --query-cache-size=0 を併用することである。(様々なステップにおいて、前述オプションを組み合わせることが有用であることから、デフォルトでは設定をしていない。)

  • --flush

    それぞれの SQL コマンドの実行後に、ディスクへ変更のすべてをフラッシュ (同期) する。通常、MySQL はそれぞれの SQL コマンドの後に、変更だけをディクスに書き込み、ディスクへの同期処理はオペレーティング システムに任せている。詳細は 項B.1.4.2. 「What to Do If MySQL Keeps Crashing」 を参照のこと。

  • --general-log[={0|1}]

    --log または -l オプションを与えた場合に、初期のログ状態を指定する。引数がない、または 0 の場合、--general-log オプションがログを無効化する。引数を省略または 1 とした場合、ログを有効化する。--log または -l を指定しない場合、--general-log の効果はない。(MySQL 5.1.12 からの導入)

  • --init-file=file_name

    サーバ起動時にこのファイルから読み込んだ SQL コマンドを実行する。それぞれのコマンドはシングル ライン (一行) で、コメントを含まないものとする。

    このオプションは、MySQL のコンフィギュレーションに --disable-grant-options オプションを使用している場合は使えない。詳細は 項2.9.2. 「典型的な configure オプション」 を参照のこと。

  • --innodb-xxx

    InnoDB オプションは 項13.5.4. 「InnoDB 起動オプションとシステム変数」 を参照のこと。

  • --language=lang_name, -L lang_name

    クライアントのエラー メッセージに使用する言語。lang_name は言語名またはフルパスで指定できる (言語情報を格納するディレクトリ)。詳細は 項4.10.2. 「英語以外のエラーメッセージ」 を参照のこと。

  • --large-pages

    オペレーティング システムによっては、デフォルト (4KB) よりも大きいメモリ ページをサポートしている。サポートの実装はハードウェアやOSに依存する。大量のメモリ アクセスがあるアプリケーションの場合には、大きなメモリ ページを使用して、パフォーマンスを改善できる可能性がある。つまり トランスレーション・ルックアサイド・バッファ (TLB; Translation Lookaside Buffer) のミスが減る。

    現在、MySQL は Linux 実装だけをサポートしている。Linux ではこれを HugeTLB と呼ぶ。 FreeBSD や Solaris、その他の OS でのサポートは計画中である。

    Linux で大きなページを使用するには、HugeTLB メモリ プールを設定する必要がある。リファレンスとして、Linux カーネル ソースの hugetlbpage.txt ファイルを参照のこと。

    このオプションのデフォルトは無効と設定している。

  • --log[=file_name], -l [file_name]

    一般クエリ ログを有効化する。一般クエリ ログにはクライアントとの接続記録とクライアントから受信した SQL文のエントリーをログしている。MySQL 5.1.6 から、ログ出力先は --log-output オプションで選択できる。MySQL 5.1.6 以前は、ログはクエリ ログ ファイルに記録している。このファイル名を省略すると、MySQL でファイル名に host_name.log を使用する。詳細は 項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 および 項4.11.3. 「一般クエリ ログ」 を参照のこと。

  • --log-bin[=base_name]

    バイナリ ログを有効化する。サーバがデータを変更するクエリをすべてバイナリ ログに記録する。これは、バックアップおよびレプリケーション用に使用できる。詳細は 項4.11.4. 「バイナリ ログ」 を参照のこと。

    オプション値を指定すると、それはログ順序のベース名 (basename) になる。サーバはベース名に数値のサフィックスを与えた配列でバイナリ ログ ファイルを作成する。ベース名指定は推奨事項である (項B.1.8.1. 「Open Issues in MySQL」 を参照のこと)。指定がない場合、MySQL で host_name-bin をベース名として扱う。

  • --log-bin-index[=file_name]

    バイナリ ログ ファイル名のインデックス ファイルを指定する。詳細は 項4.11.4. 「バイナリ ログ」 を参照のこと。ファイル名を省略する場合に、--log-bin で名前を指定しないときには、MySQL で、host_name-bin.index をファイル名として扱う。

  • --log-bin-trust-function-creators[={0|1}]

    引数なし、または 1 で、このオプションは log_bin_trust_function_creators システム変数を 1 と設定する。引数 0 の場合は、システム変数を 0 にセットする。log_bin_trust_function_creators はMySQL の格納関数 (stored function) の動作に制約を与える。詳細は 項17.4. 「ストアドルーチンとトリガのバイナリログ」. を参照のこと。

  • --log-error[=file_name]

    エラーと起動メッセージをファイルに記録する。詳細は 項4.11.2. 「エラー ログ」 を参照のこと。ファイル名を省略する場合、MySQL で host_name.err を使用する。ファイル名に拡張子がない場合は、サーバで .err という拡張子を加える。

  • --log-isam[=file_name]

    すべての MyISAM の変更をファイルに記録する。MyISAM をデバッグするときにだけ使用する。

  • --log-long-format (DEPRECATED)

    追加情報をログ ファイルに記録する(更新ログ、バイナリ更新ログ、スロー クエリ ログなど、有効化しているログのすべて)。たとえば、クエリのユーザ名とタイム スタンプを記録する。このオプションは --log-short-format の説明と同じ理由で、廃止となり、デフォルト設定になった。一方で、MySQL インデックスを使用しないクエリをスロー クエリ ログに記録するための --log-queries-not-using-indexes オプションが利用可能になっている。

  • --log-output[=value,...]

    このオプションで、一般クエリ ログとスロー クエリ ログの出力先を決める。オプション値は TABLEFILENONE など、一つ以上の文字 (words) で与える。このオプションに値がない場合、つまりデフォルトでは、TABLE で、mysql データベースのgeneral_log および slow_log テーブルに記録する。FILE は、ログ ファイルに記録する。FILE のロギングでは、 --log および -slow-log のオプションでログ ファイルの場所を決定する。NONE はロギングを無効にする。NONE がオプション値にある場合は、どの文字よりも優位になる。オプションで TABLE および FILE 両方のログ出力先を選択できる。

    ノート: このオプションはログ出力先を選択するが、ログ出力には関与しない。ログ出力を有効にするには、--log および --log-slow-queries オプションを使用する。詳細は 項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 を参照のこと。

    --log-output オプションは MySQL 5.1.6 で導入した。

  • --log-queries-not-using-indexes

    このオプションを --log-slow-queries として使用する場合、インデックスを使用しないクエリはスロー クエリ ログで記録する。詳細は 項4.11.5. 「スロー クエリ ログ」 を参照のこと。

  • --log-short-format

    ログ ファイル (更新ログ、バイナリ更新ログ、スロークエリログなど、有効化しているログのすべて) で記録する情報が少なくなる。たとえば、クエリのユーザ名とタイム スタンプを記録しなくなる。

  • --log-slow-admin-statements

    OPTIMIZE TABLEANALYZE TABLEALTER TABLEなど、時間がかかる管理系 SQL 文をスロー クエリ ログに出力する。

  • --log-slow-queries[=file_name]

    スロー クエリ ログを有効化する。実行時間が long_query_time 秒以上かかるクエリをすべてスロー ログ ファイルとして記録する。詳細については、--log-long-format オプションおよび --log-short-format オプションの説明を参照のこと。

    MySQL 5.1.6 以降でのログ出力先は --log-output で選択できる。MySQL 5.1.6 以前の場合は、ロギングはスロー クエリ ログ ファイルで行なう。このファイル名を省略すると、MySQL で host_name-slow.log をファイル名として扱う。詳細は 項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 および 項4.11.5. 「スロー クエリ ログ」 を参照のこと。

  • --log-tc=file_name

    バイナリ ログを無効にすると、複数のストレージ エンジンに影響を与える XA トランザクションに対する、メモリ マップのトランザクション コーディネータのログ ファイルの名前。デフォルト名は tc.log 。このファイルをフルパスで指定しない場合には、データ ディレクトリ下での作成になる。現段階ではこのオプションは使用していない。

  • --log-tc-size=size

    メモリ マップのトランザクションのコーディネータのログのバイト サイズ。デフォルト サイズは 24 KB。

  • --log-warnings[=level], -W [level]

    Aborted connection... などの警告をエラー ログに出力する。このオプションを有効にしておく (推奨) と、レプリケーションを行う場合に、ネットワークの問題や再接続のメッセージに関する詳細を得ることができる。このオプションは、デフォルトで有効化 (1) していて、デフォルトの level 値を省略する場合は、1 になる。このオプションを無効化するには、--log-warnings=0 を使用する。値を 1 より大きくすると、エラー ログで通信エラー (Aborted connections) を記録することになる。詳細は 項B.1.2.10. 「Communication Errors and Aborted Connections」 を参照のこと。

  • --low-priority-updates

    テーブル変更操作で、選択よりも優先順位を下げる (INSERTREPLACEDELETEUPDATE など)。 {INSERT | REPLACE | DELETE | UPDATE} LOW_PRIORITY ... を使用して 1 つのクエリだけ優先順位を低くしたり、SET LOW_PRIORITY_UPDATES=1 を使用して 1 つのスレッド内での優先順位を変更することができる。詳細は 項6.3.2. 「テーブルロック関連の問題」 を参照のこと。

  • --memlock

    メモリ内の mysqld プロセスをロックする。これは、使用しているシステムが mlockall() システム コールをサポートしている場合(Solaris など)に使用可能。たとえば、オペレーティング システムが原因で mysqld のスワップが発生するという問題がある場合、その解決に役立つ。注意: このオプションを使用するには、サーバを root として起動することが必要になるが、これは安全ではない。詳細は 項4.6.5. 「ユーザによる MySQL の実行」 を参照のこと。.

  • --myisam-recover[=option[,option]...]]

    MyISAM のストレージ エンジン のリカバリ モードをセットする。オプションは、DEFAULTBACKUPFORCEQUICK の任意の組み合わせ。複数の値を指定するにはカンマで区切る。このオプションを無効にするには、これを明示的に "" を使用する。このオプションを使用すると、mysqld はテーブルを開く一方で、MyISAM テーブルを開き、テーブルにクラッシュのマークが付いていないか、つまりテーブルを正しく閉じているかどうかをチェックする。(これは外部ロックを無効にした状態で稼動している場合にだけ機能する)。テーブルにクラッシュ マークが付いていた場合、mysqld はテーブルをチェックし、テーブルが破損していた場合は、mysqld で修復を試みる。

    次のオプションで、修復方法を決定する。

    オプション説明
    DEFAULT--myisam-recover でどのオプションも指定しないのと同じ。
    BACKUP修復時にデータ テーブルを変更する場合、tbl_name.MYD データファイルのバックアップを tbl_name-datetime.BAK として保存する。
    FORCE.MYD ファイルから複数のレコードがなくなる場合でも修復を実行する。
    QUICK削除ブロックがない場合、テーブル内のレコードをチェックしない。

    サーバはテーブルを自動的に修復する前に、エラー ログに修復するというノートを書き込む。BACKUP,FORCE を使用すると、ユーザの介入をなくして、ほとんどすべての問題をリカバリできる。このやり方は、テーブルの修復を強制的に行うことになるため、レコードを若干削除してしまう可能性を伴うが、古いデータ ファイルがバックアップとして残るので後で調べることができる。

    詳細は 項13.4.1. 「MyISAM スタートアップオプション」 を参照のこと。

  • --ndb-connectstring=connect_string

    NDB ストレージ エンジンを使用している場合、接続文字列オプションを設定して、クラスタ コンフィギュレーションを渡しているマネージメント サーバをポイントアウトできる。構文は 項14.4.4.2. 「クラスタの 接続文字列 を参照のこと。

  • --ndbcluster

    NDB Cluster ストレージ エンジンへのサポートをバイナリに組み込んでいる場合、このオプションがエンジンを有効化する。デフォルト設定では無効になっている。詳細は 章?14. MySQL Cluster を参照のこと。

  • --old-passwords

    新たなパスワードに古いパスワード形式でのハッシュ生成を強制する。(MySQL4.0 以前のパスワードを強制する。) これは、サーバが古いクライアント プログラムをサポートする必要がある場合に有用である。詳細は 項4.7.9. 「MySQL 4.1 のパスワードハッシュ」 を参照のこと。

  • --one-thread

    (Linux でのデバッグ) でスレッドを一つだけにする。サーバでのデバッグが有効化している場合にだけ使用できる。詳細は Debugging a MySQL Server を参照こと。

  • --open-files-limit=count

    mysqld で使用可能なファイル記述子の数を変更する。これが設定されていない、または 0 で設定する場合、mysqld は、setrlimit() で使用している値を使用してファイル記述子をリザーブする。値が 0 の場合、mysqldmax_connections×5 または max_connections + table_open_cache×2 のどちらか大きい値をファイル数としてリザーブする。mysqldToo many open files のエラーが出る場合、この値を大きくする。

  • --pid-file=path

    プロセス ID (PID) ファイルのパス。mysqld_safe など、別プログラムでサーバの PID を指定するときに使用するファイルのこと。

  • --port=port_num, -P port_num

    TCP/IP 接続時に使用するポート番号を指定する。ポート番号は 1024 以上にする。サーバが root システム ユーザで立ち上がっている場合はこの限りではない。

  • --port-open-timeout=num

    このオプションは TCP/IP ポートが開かない場合に、何秒待機するかを示す。システムによっては、サーバ停止後、すぐには TCP/IP ポートを使用できない。サーバを終了した直後に再起動すると、サーバは失敗する可能性のあるポートを再び開けようとする。デフォルト設定では待機しない、と指定している。(MySQL 5.1.5 からの導入)

  • --safe-mode

    いくつかの最適化ステージをスキップする。

  • --safe-show-database (DEPRECATED)

    詳細は 項4.7.3. 「MySQL 提供の権限」 を参照のこと。

  • --safe-user-create

    これを有効化した場合、ユーザに mysql.user テーブルまたはそのテーブル内のカラムに対する INSERT 権限がなければ、GRANT コマンドを使用して新規ユーザを作成できなくなる。

  • --secure-auth

    クライアントからの古いパスワード形式 ((MySQL4.1 より前の形式)) による認証を許可しない。

  • --shared-memory

    ローカル クライアントとの共有メモリ接続を有効化する。 このオプションは Windows にだけ使用できる。

  • --shared-memory-base-name=name

    共有メモリ接続で使用する共有メモリの名前を指定します。 このオプションは Windows にだけ使用できる。デフォルトの名前は MYSQL。この名前は大文字と小文字を区別する。

  • --skip-concurrent-insert

    MyISAM テーブルに対する SELECT 文と INSERT 文の同時実行を無効化する。このオプションは、この動作に関してバグの可能性があるときにだけ有効化する。詳細は 項6.3.3. 「同時挿入」 を参照のこと。

  • --skip-external-locking

    外部ロック (システム ロック) を使わないようにする。外部ロックが無効化している場合に、myisamchk を使用するときには、サーバをシャットダウンする (項6.5.1. 「システム、コンパイル時間およびスタートアップパラメータのチューニング」 参照)。外部ロックを回避すには。 これを不要にするには、CHECK TABLE および REPAIR TABLE 文をチェックに使用して、MyISAM テーブルを修正する。

    MySQL 4.0 以降、外部ロックのデフォルト設定では、無効化している。

  • --skip-grant-tables

    サーバが一切の権限システムを使用しないようにする。つまり、誰でも すべてのデータベースにフルアクセスできる ようになる。サーバ実行中に、権限テーブルの行使を再開するには、mysqladmin flush-privileges または mysqladmin reload をシステム シェルから実行するか、またはサーバ接続後に MySQL FLUSH PRIVILEGES ステートメントを発行する。このオプションはまた、プラグインとユーザ定義関数 (UDF) のロードを抑制する。

    このオプションは、MySQL のコンフィギュレーションに --disable-grant-options オプションを使用している場合は使えない。詳細は 項2.9.2. 「典型的な configure オプション」 を参照のこと。

  • --skip-host-cache

    name-to-IP の解決に、ホスト名のキャッシュを使用せず、接続ごとに DNS サーバに対しクエリを発行する。詳細は 項6.5.6. 「MySQLの DNS の使用」 を参照のこと。

  • --skip-innodb

    InnoDB ストレージ エンジンを無効にする。メモリとディスク領域の節約および演算処理のスピードアップに役立つ。InnoDB テーブルを必要とする場合は、このオプションを使用しない。

  • --skip-name-resolve

    (MySQLでのDNS逆引きを無効にする。) クライアント接続のチェックに、IPアドレスからホスト名を割り出す。このオプションを使用する場合には、権限テーブルの Host カラム値すべてが IP アドレスまたは localhost であることが必要。詳細は 項6.5.6. 「MySQLの DNS の使用」 を参照のこと。

  • --skip-ndbcluster

    NDB Cluster ストレージ エンジンを無効にする。NDB Cluster ストレージ エンジン サポートを投じたバイナリではデフォルトである。--ndbcluster オプションを明示的に与えると、サーバはこのストレージ エンジンのメモリや別リソースを配分する。使用例に関しては 項14.4.3. 「MySQL Cluster の簡単なテストの設定」 を参照のこと。

  • --skip-networking

    TCP ポートを一切使用しない。mysqld とのやり取りはすべて、名前付きパイプ、共有メモリ ( Windows) または Unix ソケット ファイル (Unix) を介して行う必要がある。ローカルからの接続要求のみを許可しているシステムにおいては、特にこのオプションを使用する (推奨)。詳細は 項6.5.6. 「MySQLの DNS の使用」 を参照のこと。

  • --ssl*

    --ssl で始まるオプションは、SSL経由での接続をクライアントに許可するかどうかを指定し、SSL キーと証明書 がどこにあるかを示す。詳細は 項4.8.7.3. 「SSL コマンド オプション」 を参照のこと。

  • --standalone

    Windows NT システム専用。MySQL サーバをサービスとして起動せずにスタンドアロンで起動する。

  • --symbolic-links, --skip-symbolic-links

    シンボリック リンクのサポートを有効化または無効化する。このオプションは、Windows と Unix では効果が異なる。

  • --skip-safemalloc

    MySQL を --with-debug=full で設定する場合、すべてのプログラムが、メモリの割り当て時と解放時に必ずメモリのオーバーランをチェックする。このチェックには時間がかかるため、このチェックが不要のサーバに対しては、--skip-safemalloc オプションを使用して、チェックをスキップできる。

  • --skip-show-database

    ユーザが SHOW DATABASES 権限を持っていない場合に、SHOW DATABASES コマンドを無効化する。ステートメントはすべてのデータベース名を表示する。このオプションをセットしない場合、SHOW DATABASES はすべてのユーザが利用できるようになるが、ユーザが SHOW DATABASES 権限、またはそのデータベースに関する何らかの権限を持っているときには、それぞれのデータベース名だけを表示する。注意:すべての グローバル権限がデータベースに対する権限になる。

  • --skip-stack-trace

    スタック トレースを書き込まないようにする。このオプションは、デバッガで mysqld を実行するときに役立つ。システムによっては、コア ファイルを取得するためにこのオプションの使用が必要な場合がある。詳細は Debugging a MySQL Server を参照のこと。

  • --skip-thread-priority

    応答時間を短くするため、スレッド優先度の使用を無効化する。

  • --slow-query-log[={0|1}]

    --log-slow-queries オプションで、イニシャルのログ状態を指定する。引数がない、または 0 の場合、--slow-query-log オプションがログを無効化する。省略または 1 を引数とした場合、このオプションはログを有効化する。--log または -l を指定しない場合、--slow-query-log の効果はない。(MySQL 5.1.12 での導入)

  • --socket=path

    Unix では、ローカル接続に使用するソケットファイルを指定する。デフォルトは /tmp/mysql.sock 。Windows では、名前付きパイプのローカル接続用パイプ名を指定する。デフォルトは MySQL (大小文字の区別なし)。

  • --sql-mode=value[,value[,value...]]

    SQL モードを設定する。詳細は 項4.2.6. 「SQL モード」 を参照のこと。

  • --sysdate-is-now

    デフォルトの SYSDATE() が実行タイムを返す。これは実行を開始するステートメントのタイムではない。NOW() の動作によって異なる。このオプションを使用すると、SYSDATE()NOW() のエイリアスになる。バイナリ ロギングやレプリケーションの実装に関しては、項11.5. 「日付時刻関数」SYSDATE() 用の説明と、項12.5.3. 「SET 構文」SET TIMESTAMP 用の説明を参照のこと。

    (MySQL 5.1.8 での追加)

  • --tc-heuristic-recover={COMMIT|ROLLBACK}

    ヒューリスティック のリカバリ プロセスで使用する決定型 (発見的方法)。現段階では、このオプションは未使用である。

  • --temp-pool

    このオプションを使用すると、サーバが作成する大部分のテンポラリ ファイルに、それぞれ一意の名前ではなく、小さな名前のセットを使用する。これで、名前が異なる新規作成ファイルが多い場合に、それを Linux カーネルが処理するときの問題を回避する。Linux では、メモリがディスク キャッシュではなく、ディレクトリ エントリ キャッシュへの割り当てになるため、従来の動作ではメモリの 「リーク」 が発生しやすい。

  • --transaction-isolation=level

    デフォルトのトランザクション隔離レベルを指定する。level 値は、READ-UNCOMMITTEDREAD-COMMITTEDREPEATABLE-READSERIALIZABLE などになり得る。詳細は 項12.4.6. 「SET TRANSACTION 構文」 を参照のこと。

  • --tmpdir=path, -t path

    テンポラリ ファイル作成に使用するディレクトリのパス。テンポラリ ファイルを保存するには小さすぎるパーティション上にデフォルトの /tmp ディレクトリがある場合、このオプションが役に立つ。このオプションではラウンド ロビン方式のパスを使用できる。Unix ではコロン(‘:’)を、Windows、NetWare、OS/2 ではセミコロン(‘;’)でパスを区切る。MySQL サーバがレプリケーション スレーブとして機能している場合は、メモリベースのファイルシステムのディレクトリや、サーバ ホストのリブートでクリアするディレクトリを指すときには、--tmpdir を設定しない。テンポラリ ファイルのストレージ位置に関しては、項B.1.4.4. 「Where MySQL Stores Temporary Files」 を参照のこと。スレーブは、マシンがリブートしてもテンポラリ テーブルのレプリケーション、または LOAD DATA INFILE のレプリケーション処理を続行するためにテンポラリファイルを必要とする。サーバの再起動時に、テンポラリ ファイル ディレクトリのファイルが消えた場合、レプリケーションは失敗に終わる。

  • --user={user_name|user_id}, -u {user_name|user_id}

    mysqld サーバを、user_name (名前)、または user_id (数字のユーザ ID) を保持するユーザで実行する。ここでの 「ユーザ」 は、権限テーブルにリストしている MySQL ユーザではなく、システム ログイン アカウントのこと)。

    mysqldroot アカウントで起動する場合には、必須 のオプションである。起動シーケンス中にサーバがそのユーザ ID を変更し、root ではなく、特定のユーザで実行するようになる。詳細は 項4.6.1. 「セキュリティ ガイドライン」 を参照のこと。

    セキュリティ ホールを回避するため、つまりユーザが --user=root オプションを my.cnf ファイルに追加することが原因で、その結果、サーバが root として稼動できないようにするために、mysqld で最初に指定した --user オプションだけを使用し、複数の --user オプションがあった場合に警告を生成する。/etc/my.cnf および $MYSQL_HOME/my.cnf 内のオプションは、コマンドラインのオプションより先に処理することになるため、--user オプションを /etc/my.cnf に含めた上で、root 以外の値を指定する (推奨)。/etc/my.cnf 内のオプションが他の --user オプションよりも先に検出することになるので、サーバは確実に root 以外のユーザが実行することになり、別の --user オプションを検地すると警告を出す。

  • --version, -V

    バージョン情報を表示して、終了する。

--var_name=value という配列のオプションを使用して、サーバのシステム変数に値を割り当てることができます。たとえば、--key_buffer_size=32Mkey_buffer_size の変数を 32 MB という値に設定できます。

注意:変数として値を割り当てるときには、MySQL が自動的に範囲内に留まろうとして、値を修正する可能性があります。あるいは、特定の値を許可している場合には、許容値との近似値に調整しようとする可能性もあります。

SET のランタイムに設定できる変数の最大値を制限する場合には、--maximum-var_name=value をコマンドラインのオプションを使用して、定義できます。

または、--set-variable=var_name=value あるいは -O var_name=value のシンタックスを使用して、変数を設定することも可能です。このシンタックスは廃止予定です。

SET コマンドを使用して、実行中のサーバに対して対部分のシステム変数の値を変更できます。詳細は 項12.5.3. 「SET 構文」 を参照してください。

すべての変数の詳細に加え、サーバのスタートアップやランタイムで設定する方法に関する追加情報は、項4.2.3. 「システム変数」 を参照してください。システム変数を調整したサーバの最適化に関する情報は項6.5.2. 「サーバパラメータのチューニング」 を参照してください。

4.2.3. システム変数

mysql サーバは、様々なシステム変数を保有しています。そしてその変数は、設定がどのようになっているかを示します。それぞれのシステム変数にはデフォルト値がありますが、サーバ起動時に、コマンドラインまたはオプション ファイルなどを使用して変更できます。大抵の場合、SET コマンドを使用して実行中のサーバで動的に変更できます。つまり、サーバを停止または再起動などで操作を中断しなくても変更することが可能であるということです。システム変数の値は、プログラミング式で指定します。

システム変数の名前や値を確認する方法 (コマンド)

  • サーバで使用しているコンパイルのデフォルト値や、読み込むオプション ファイルの所在を確認するコマンド

    mysqld --verbose --help
    
  • サーバが元にするコンパイルのデフォルト値や、オプション ファイルの設定がどうなっているか (無視するかどうか) を確認するコマンド

    mysqld --no-defaults --verbose --help
    
  • 実行中のサーバでカレント値を確認するには、SHOW VARIABLES ステートメントを使用すること。

このセクションでは、それぞれのシステム変数について説明します。バージョン情報を記載していない変数は、MySQL 5.1 リリースで導入した変数です。実装/導入履歴に関する情報は、MySQL 5.0 Reference Manual または MySQL 3.23, 4.0, 4.1 リファレンス マニュアル をそれぞれ参照してください。

その他のシステム変数に関する詳細は、次のセクションを参照してください。

ノート:次に示す変数説明は、変数を 「可能にする (有効化)」 または 「不可能にする (無効化)」 ということに言及しています。これらの変数は SET コマンドを ON または 1 に設定すると実行可能であることを示し、あるいは OFF または 0 に設定すると実行不可能であることを示します。コマンドラインまたはオプション ファイルで変数を設定するには、1 または 0 のいずれかを使用してください。ON または OFF を使用すると機能しません。たとえば、コマンドラインの場合に、--delay_key_write=1 のオプションは動作しますが、 --delay_key_write=ON では動作しません。

バッファ サイズ、長さ、スタック サイズなどの値は、指定がない限り、バイトで与えます。

  • auto_increment_increment

    auto_increment_incrementauto_increment_offset はマスタからマスタへのレプリケーションに使用する。AUTO_INCREMENT カラムの操作の制御に使用できる。この変数には、グローバルまたはローカルで設定でき、それぞれで 1 から 65,535 までの整数を使用できる。これら 2 種類の変数のどちらかを 0 に設定すると、1 での設定したものとの解釈になる。65,535 より大きな整数、あるいは 0 ではない数字でこれらの変数のどちらかを設定すると、65,535 で設定したものとの解釈になる。auto_increment_increment または auto_increment_offsetに、整数以外の値を使用すると、反映できずエラーになり、変数の実際の値 (デフォルト) のままになる。

    重要 auto_increment_incrementauto_increment_offset は MySQL Cluster レプリケーションには使用しないでください。MySQL Cluster レプリケーションでこの 2 つの変数を使用すると、予期せぬエラーまたは回復不能な状態にある可能性があります。そのため、Cluster レプリケーションでの この 2 つの変数においては、サポートしていません。

    これら 2 つの変数は AUTO_INCREMENT カラムの動作に次のように影響する。

    • auto_increment_increment は自動インクリメントの間隔値を制御する。次はその例示である。

      mysql> SHOW VARIABLES LIKE 'auto_inc%';
      +--------------------------+-------+
      | Variable_name            | Value |
      +--------------------------+-------+
      | auto_increment_increment | 1     |
      | auto_increment_offset    | 1     |
      +--------------------------+-------+
      2 rows in set (0.00 sec)
      
      mysql> CREATE TABLE autoinc1
          -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
        Query OK, 0 rows affected (0.04 sec)
      
      mysql> SET @@auto_increment_increment=10;
      Query OK, 0 rows affected (0.00 sec)
      
      mysql> SHOW VARIABLES LIKE 'auto_inc%';
      +--------------------------+-------+
      | Variable_name            | Value |
      +--------------------------+-------+
      | auto_increment_increment | 10    |
      | auto_increment_offset    | 1     |
      +--------------------------+-------+
      2 rows in set (0.01 sec)
      
      mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
      Query OK, 4 rows affected (0.00 sec)
      Records: 4  Duplicates: 0  Warnings: 0
      
      mysql> SELECT col FROM autoinc1;
      +-----+
      | col |
      +-----+
      |   1 |
      |  11 |
      |  21 |
      |  31 |
      +-----+
      4 rows in set (0.00 sec)
      

      注意: ここでは SHOW VARIABLES を変数値 (カレント値) を取得する目的で使用しています。

    • auto_increment_offsetAUTO_INCREMENT カラム値の開始点を決定する。次の例示は、 auto_increment_increment 記述の例で、ステートメントを同一のセッション中に実行した場合である。

      mysql> SET @@auto_increment_offset=5;
      Query OK, 0 rows affected (0.00 sec)
      
      mysql> SHOW VARIABLES LIKE 'auto_inc%';
      +--------------------------+-------+
      | Variable_name            | Value |
      +--------------------------+-------+
      | auto_increment_increment | 10    |
      | auto_increment_offset    | 5     |
      +--------------------------+-------+
      2 rows in set (0.00 sec)
      
      mysql> CREATE TABLE autoinc2
          -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
      Query OK, 0 rows affected (0.06 sec)
      
      mysql> INSERT INTO autoinc2 VALUES (NULL), (NULL), (NULL), (NULL);
      Query OK, 4 rows affected (0.00 sec)
      Records: 4  Duplicates: 0  Warnings: 0
      
      mysql> SELECT col FROM autoinc2;
      +-----+
      | col |
      +-----+
      |   5 |
      |  15 |
      |  25 |
      |  35 |
      +-----+
      4 rows in set (0.02 sec)
      

      auto_increment_offset の値が、auto_increment_increment の値よりも大きい場合、auto_increment_offset の値は無効になる。

    ここで、これら変数のどちらか、あるいは両方が変更して、新規の行をテーブルの AUTO_INCREMENT カラムに挿入していなければならない。結果は直感的のようにも思えるが、これは既にカラムに存在している値を無視して、AUTO_INCREMENT 値で計算している。つまり、挿入した値が AUTO_INCREMENT カラムの最大値よりも大きいシリーズの最小値であることが原因である。つまり、シリーズが次のように計算したことに起因する。

    auto_increment_offset + N × auto_increment_increment

    N が [1, 2, 3, ...] のシリーズの正の整数。たとえば次の例示の通り。

    mysql> SHOW VARIABLES LIKE 'auto_inc%';
    +--------------------------+-------+
    | Variable_name            | Value |
    +--------------------------+-------+
    | auto_increment_increment | 10    |
    | auto_increment_offset    | 5     |
    +--------------------------+-------+
    2 rows in set (0.00 sec)
    
    mysql> SELECT col FROM autoinc1;
    +-----+
    | col |
    +-----+
    |   1 |
    |  11 |
    |  21 |
    |  31 |
    +-----+
    4 rows in set (0.00 sec)
    
    mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
    Query OK, 4 rows affected (0.00 sec)
    Records: 4  Duplicates: 0  Warnings: 0
    
    mysql> SELECT col FROM autoinc1;
    +-----+
    | col |
    +-----+
    |   1 |
    |  11 |
    |  21 |
    |  31 |
    |  35 |
    |  45 |
    |  55 |
    |  65 |
    +-----+
    8 rows in set (0.00 sec)
    

    auto_increment_incrementauto_increment_offset で示している値は、5 + N × 10 のシリーズを生成する。つまり、[5, 15, 25, 35, 45, ...] である。INSERT 前の col カラムの最大値は 31 で、AUTO_INCREMENT シリーズで次に利用可能な値は 35 。そして col の挿入値はその時点から始まり、その結果が SELECT クエリの表示になる。

    ここで重要なことは、1 つのテーブルにこれら 2 つの変数をした場合の効果を制限することはできないということである。ゆえに、別のデータベース管理システムで提供しているシーケンスとは併用できない。この変数は、MySQL サーバの すべて のテーブルにある AUTO_INCREMENT カラムのすべての動作を制御する。この変数のどちらかをグローバルでセットした場合、グローバル値を変更するか、またはローカルでこれらを設定して上書きするまで、あるいは mysqld が再起動するまで、その効果が続くことになる。ローカルで設定した場合、新しい値はすべてのテーブルの AUTO_INCREMENT カラムに影響し、そのセッションのユーザが新たな行を挿入することになる。つまり値がセッション中に変更することになる。

    auto_increment_increment のデフォルト値は 1 。詳細は 項5.2.3.1. 「Auto-Increment in Multiple-Master Replication」 を参照のこと。

  • auto_increment_offset

    この変数のデフォルト値は 1。auto_increment_increment での記述も参照のこと。

  • automatic_sp_privileges

    この変数が 1 (デフォルト) の場合、サーバが自動的に EXECUTE および ALTER ROUTINE の権限をストアド ルーチンのクリエータに与える。(ALTER ROUTINE 権限で、ルーチンをドロップの対象にする。) つまりサーバが、クリエータのルーチンをドロップするときに、自動的にこの権限もドロップする。automatic_sp_privileges が 0 の場合、サーバは自動的にはドロップしない。権限もドロップの対象にはならない。

  • back_log

    MySQL で保持できる未解決の接続要求数。これは、短時間にメインの MySQL スレッドに多くの接続要求が集中したときに機能する (役立つ)。そして、メイン スレッドが接続をチェックするため、新規スレッドの開始には時間(若干)がかかる。つまり back_log 値は、MySQL が一時的に新規要求への回答を停止するまでの瞬時に、スタック可能な要求の数を示す。短時間に多くの接続要求数がある場合にだけ、この値を大きくする。

    つまり、この値は、TCP/IP 接続のリッスン キューのサイズである。使用しているオペレーティング システムそのものにも、このキュー サイズの制限がある。詳細については、Unix listen() システムコールのマニュアルページを参照のこと。この変数の最大値については、OS のドキュメントを参照する。back_log を、オペレーティングシステムの制限値より大きくしても、効果はない。

  • basedir

    基準パスを指定する。MySQL をインストールしたディレクトリを指す。--basedir オプションで起動時に設定できる。

  • binlog_cache_size

    トランザクション中にバイナリ ログに対する SQL ステートメントを保持するキャッシュのサイズ。(トランザクション間でメモリに保持する SQL文の最大数。) サーバがトランザクションのストレージ エンジンをサポートする場合、あるいはサーバで --log-bin オプションを使用して、バイナリ ログを可能にしている場合、バイナリ ログ キャッシュをクライアントに割り当てる。大きな複数ステートメントのトランザクションが頻繁にある場合、この値を大きくすると、パフォーマンスを向上できる。Binlog_cache_useBinlog_cache_disk_use のステータス変数はこの変数のサイズ調整に便利である。詳細は 項4.11.4. 「バイナリ ログ」 を参照のこと。

  • binlog_format

    バイナリ ロギング形式。STATEMENTROWMIXED のどれかになる。binlog_format は 起動時に --binlog-format オプションで設定する。または、ランタイムで binlog_format 変数でも設定できるが、グローバル スコープでこの変数を設定するには、SUPER 権限が必要になる (項5.1.2. 「レプリケーション フォーマット」 を参照のこと)。(スタートアップ変数の導入:MySQL 5.1.5、ランタイム変数の導入:MySQL 5.1.8、MIXED の導入:MySQL 5.1.8)

    デフォルトでは STATEMENT を使用。MIXED を指定して、ステートメント ベースのレプリケーションにすることもできる。ただし、行ベースのレプリケーションで正確な結果を保証する場合 (その必要がある場合)、たとえば、ユーザ定義関数 (UDF)、または UUID() 関数を含むステートメントの場合には、この限りではない (別の事情がある)。格納ルーチン (stored functions) やトリガなどに、MIXED を指定して、ステートメント ベースのレプリケーションを行う場合も例外である。

    ランタイムでレプリケーションの仕方を切り替えることができない場合

    • 格納関数またはトリガ内からの場合

    • NDB を有効化している場合

    • セッションのレプリケーション モードが行ベースで、テンポラリ テーブルを開けている場合

    この 3 つのどれかに該当する場合に、レプリケーションの仕方を変更すると、エラーになる。

    MySQL 5.1.8 前は、行ベース レプリケーションの仕方を変更することは --log-bin-trust-function-creators=1 および --innodb_locks_unsafe_for_binlog を明示的に設定するとしていた。しかし、MySQL 5.1.8 以降 (MySQL 5.1.8 を含む) は、行ベースのレプリケーションにこのオプションで明示設定しても、通用しない。

  • bulk_insert_buffer_size

    空白ではないテーブルにデータを追加する場合に、MyISAM は特殊なツリー状のキャッシュを使用して、バルクの INSERT ... SELECTINSERT ... VALUES (...), (...), ...LOAD DATA INFILEを高速化する。この変数で、スレッドごとのキャッシュ ツリーのサイズを制限する(バイト単位)。この値を 0 に設定すると、最適化は無効になる。デフォルト値は 8 MB 。

  • character_set_client

    クライアント送信の文字列のキャラクタ セット (クライアントが送信するキャラクタ セット)。

  • character_set_connection

    キャラクタ セット情報がないリテラルの並びで、数値→文字と変換するときのキャラクタ セット。

  • character_set_database

    デフォルト データベースで使用するキャラクタ セット。デフォルト データベースが変化する度に、サーバがこの変数を変更する。デフォルト データベースが存在しない場合、この値は character_set_server と同一。

  • character_set_filesystem

    ファイルシステムのキャラクタ セット。LOAD DATA INFILESELECT ... INTO OUTFILE などのステートメントや LOAD_FILE() 関数に対して、この変数でファイル名とリテラルの文字列を読み取る。ファイルを開けようとすると、ファイル名が character_set_client から character_set_filesystem に変わる。デフォルト値は binary (変換が起こらない) である。マルチ バイトのファイル名を利用できるシステムでは、異なる値を使用することが好ましい。たとえば、UTF-8 でファイル名を表示しているシステムの場合は、character_set_filesytem'utf8' にセットする。(MySQL 5.1.6 実装)

  • character_set_results

    クライアントへ返す文字列 (クエリ結果) のキャラクタ セット。

  • character_set_server

    サーバのデフォルトのキャラクタ セット。

  • character_set_system

    識別子の書き出しにサーバが使用するキャラクタ セット。この値は常に utf8

  • character_sets_dir

    キャラクタ セットを格納しているディレクトリ。

  • collation_connection

    接続キャラクタ セットの照合順序。

  • collation_database

    デフォルト データベースの照合順序。デフォルト データベースが変化する度に、サーバがこの変数を変更する。デフォルトデータベースが存在しない場合、この値は collation_server と同一。

  • collation_server

    サーバのデフォルトの照合順序

  • completion_type

    トランザクションのコンプリーション タイプ

    • 値が 0 (デフォルト) の場合、COMMIT および ROLLBACK には影響しない。

    • 値が 1 の場合、COMMITCOMMIT AND CHAINに、ROLLBACKROLLBACK AND CHAIN に相当する。(新たなトランザクションが終了したばかりのトランザクションと同一の分離レベルで始まる。)

    • 値が 2 の場合、COMMITCOMMIT RELEASE に、ROLLBACKROLLBACK RELEASE に相当する。(サーバはトランザクションを終えると切断する。)

  • concurrent_insert

    ON (デフォルト) の場合、INSERT および SELECT ステートメントを MyISAM テーブルで同時に実行できる (間にフリー ブロックがない場合)。このオプションを使用しないように設定するには、mysqld--safe または --skip-new で起動する。

    この変数では次の整数値を使う。

    説明
    0オフ
    1(デフォルト) ホールがない MyISAM テーブルに同時挿入
    2すべての MyISAM テーブルに同時挿入。テーブルにホールがあり、別のスレッドで使用している場合、新規の行はテーブル末尾への挿入となる。テーブルが使用中でなければ、MySQL が通常の読み込みロックを行い、新規の行をホールへ挿入する。

    項6.3.3. 「同時挿入」 を参照のこと。

  • connect_timeout

    mysqld サーバが、Bad handshake を返すまで、接続パケットを待つ秒数

  • datadir

    MySQL をインストールしたディレクトリ。この変数は --basedir オプションで設定できる。

  • date_format

    この変数は実装していない。

  • datetime_format

    この変数は実装していない。

  • default_week_format

    デフォルト モード値。WEEK() 関数に使う。詳細は 項11.5. 「日付時刻関数」 を参照のこと。

  • delay_key_write

    MyISAM テーブルにだけ使えるオプション。この値は、CREATE TABLE ステートメントに使用するときに、DELAY_KEY_WRITE テーブル オプションの処理に影響する。次の表で値の詳細を参照のこと。

    オプション説明
    OFFDELAY_KEY_WRITE は無視。
    ONMySQL は CREATE TABLE ステートメント指定の DELAY_KEY_WRITE オプションを優先する。(デフォルト)
    ALL新規の開テーブルすべてを DELAY_KEY_WRITE オプションを実行可能にして作成したかのように処理する。

    DELAY_KEY_WRITE をテーブルに対して可能にした場合、インデックス更新でキー バッファのフラッシュではなく、テーブルが閉じたときにだけフラッシュする。これを利用すると、キーの書き込みスピードを速めることが可能である。ただし、これを使用する場合には、--myisam-recover オプションでサーバを立ち上げて、すべての MyISAM テーブルの自動チェックを設定しておく必要がある (例: --myisam-recover=BACKUP,FORCE)。詳細は 項4.2.2. 「コマンド オプション」 および 項13.4.1. 「MyISAM スタートアップオプション」 を参照のこと。

    ノート: --external-locking で外部ロックを有効化した場合、遅延キー書き込み (delayed key write) があるテーブルのインデックス破損に対するプロテクションがなくなる。

  • delayed_insert_limit

    delayed_insert_limit レコードを挿入後、INSERT DELAYED ハンドラは、保留中の SELECT ステートメントがあるかどうかチェックする。ステートメントがある場合、ハンドラは処理を続行する前に保留中のステートメントの実行を許可する。

  • delayed_insert_timeout

    INSERT DELAYED ハンドラ スレッドが INSERT ステートメントを待機する時間。

  • delayed_queue_size

    INSERT DELAYED を処理時のテーブルあたりのキューの最大値(レコード単位)。キューが最大値に達すると、INSERT DELAYED を実行するすべてのクライアントは、キューに空きができるまで待機する。

  • div_precision_increment

    この変数は、小数点以下の桁数を示す。DIV演算子(/) での演算結果を高める。デフォルト値は 4 。最小値は 0 、最大値は 30。次の例はデフォルト値を高めた場合の効果を示す。

    mysql> SELECT 1/7;
    +--------+
    | 1/7    |
    +--------+
    | 0.1429 |
    +--------+
    mysql> SET div_precision_increment = 12;
    mysql> SELECT 1/7;
    +----------------+
    | 1/7            |
    +----------------+
    | 0.142857142857 |
    +----------------+
    
  • event_scheduler

    この変数は Event Scheduler (イベント スケジューラ) のステータス (状態) を示す。MySQL 5.1.12 から予定している値は、ONOFFDISABLEDOFF をデフォルトとする。Event Scheduler 操作における、この変数とその効果は、 リンク (Events 関連の概略) を参照のこと。

    (MySQL 5.1.6 での追加)

  • engine_condition_pushdown

    この変数は、NDB に適用する。デフォルトでは 0 (OFF)。SELECT * FROM t WHERE mycol = 42 のように mycol でインデックス化してないカラムのクエリを実行する場合、そのクエリは NDB ノード毎にフル テーブル スキャンの対象になる。それぞれのノードで SQL サーバにすべての行 (レコード) を送り、 WHERE 条件なる。engine_condition_pushdown を 1 (ON) にセットすると、条件はストレージ エンジンまで 「押し下げられ」、NDB ノードにまで届く。それぞれのノードでスキャンを行う条件を持っているため、MySQL サーバにその条件に適合する行を送り返す。

  • expire_logs_days

    バイナリ ログの自動削除の日数を指定する。 デフォルトは 0 で 「自動削除しない」 ことを意味する。MySQLサーバ起動時もしくは ログをローテートするときが、ログを削除するタイミングである。

  • flush

    ON の場合、SQL ステートメントの後で、サーバがすべての変更をデスクにフラッシュ (同期) する。通常、MySQL は、SQL ステートメントで、すべての変更をデスクに書き込むことはなく、オペレーティング システムにディスクとの同期を任せる。項B.1.4.2. 「What to Do If MySQL Keeps Crashing」 を参照のこと。--flush オプションで mysqld を立ち上げる場合には、この変数を ON に設定する。

  • flush_time

    これを 0 以外の値に設定する場合、リソースの解放と未フラッシュ データのディスクへ同期するために、flush_time 秒ごとにすべてのテーブルを閉じる。Windows 9x、Me など別リソースに限りがあるシステムの場合にだけ、このオプションを使用する (推奨)。

  • ft_boolean_syntax

    IN BOOLEAN MODE を使用しているブーリアン全文検索をサポートする演算子一覧。詳細は 項11.7.1. 「ブール全文検索」 を参照のこと。

    デフォルトの変数値は '+?-><()~*:""&|' である。この値を変更するときのルールは次の通り。

    • 演算子の関数を文字列中の位置で決定している。

    • 置換値は 14 文字である。

    • 文字に ASCII の非英数字を使用している。

    • 最初 (先頭) または2番目の文字がスペース (空白文字) である。

    • 重複する文字を使用していない。(11 または 12 番目にクオート文字の重複は可。この2文字は同一である必要はないが、同一でなければならないこともある。)

    • 10、13、14番目の文字である。(デフォルトでは ‘:’、‘&’、‘|’) はリザーブである。

  • ft_max_word_len

    FULLTEXT インデックスの単語 (word) の最大文字数

    ノート:FULLTEXT インデックスは、変数を変更すると、再ビルドしなければならない。REPAIR TABLE tbl_name QUICK を使用のこと。

  • ft_min_word_len

    FULLTEXT インデックスの単語の最小文字数

    ノート:FULLTEXT インデックスは、変数を変更すると、再ビルドしなければならない。REPAIR TABLE tbl_name QUICK を使用のこと。

  • ft_query_expansion_limit

    WITH QUERY EXPANSION を使用した全文検索の最上位マッチ数。

  • ft_stopword_file

    全文検索のストップワード リストのファイル。ファイル内のすべてのストップワードが使用対象になるが、コメントは使用しない。デフォルトは、ストップワードの組み込みリストを使用する ( storage/myisam/ft_static.c ファイルの定義)。このパラメータを空白の文字列('')に設定すると、ストップワードのフィルタリングを無効化する。

    ノート:変数またはストップワードの内容を変更すると、FULLTEXT インデックスを再ビルドしなければならない。REPAIR TABLE tbl_name QUICK を使用のこと。

  • general_log

    一般クエリ ログを有効化しているかどうかを示す。値が 0 (または OFF) の場合、ログしない。値が 1 (または ON) の場合、ログする。デフォルトは --log オプションを設定しているかどうかによる。ログ出力先は log_output システム変数で制御する。値を NONE にした場合、ログできるようにしていても、エントリを書き込まない。(general_log は MySQL 5.1.12 での導入)

  • general_log_file

    一般クエリ ログ ファイルの名前。デフォルトは host_name.log 。初期値は --log オプションで変更可能。(MySQL 5.1.12 から導入)

  • group_concat_max_len

    GROUP_CONCAT() 関数の最大許容結果長さ (返却値の最大文字数) デフォルトは 1024 。

  • have_archive

    YESmysqldARCHIVE テーブルをサポートする場合。NO: そうでない場合。

  • have_blackhole_engine

    YESmysqldBLACKHOLE テーブルをサポートしている場合。 NO :そうでない場合。

  • have_compress

    YESzlib 圧縮ライブラリをサーバで利用できる場合。NO :そうでない場合 (このときは、COMPRESS() および UNCOMPRESS() 関数は使用できない)。

  • have_crypt

    YEScrypt() システム コールをサーバで利用きる場合。NO :そうでない場合 (このときは、ENCRYPT() 関数は使用できない)。

  • have_csv

    YESmysqldARCHIVE テーブルをサポートする場合。 NO :そうでない場合。

  • have_dynamic_loading

    YESmysqld で動的ロードのプラグインをサポートする場合。 NO :そうでない場合。(MySQL 5.1.10 から導入)

  • have_example_engine

    YESmysqldEXAMPLE テーブルをサポートしている場合。 NO :そうでない場合。

    have_federated_engine

    YESmysqldFEDERATED テーブルをサポートする場合。 NO :そうでない場合。

  • have_geometry

    YES :サーバで空間データ型 (spatial) をサポートしている場合。NO そうでない場合

  • have_innodb

    YESmysqldInnoDB テーブルをサポートしている場合。DISABLED--skip-innodb を使用している場合。

  • have_ndbcluster

    YESmysqldNDB Cluster テーブルをサポートしている場合。DISABLED--skip-ndbcluster を使用している場合。

  • have_partitioning

    YESmysqld でパーティショニング (領域確保) をサポートしている場合。(MySQL 5.1.1 から導入。MySQL 5.1.6 では、have_partition_engine から have_partioning になった (改名)。

  • have_openssl

    YESmysqld で SSL 接続をサポートする場合。 NO :そうでない場合。

  • have_query_cache

    YESmysqld で クエリ キャッシュをサポートする場合。 NO :そうでない場合。

  • have_row_based_replication

    YES :サーバで行ベースのバイナリ ロギングのレプリケーションを実行できる場合。NO : サーバでステートメント ベースのロギングを行う。詳細は 項5.1.2. 「レプリケーション フォーマット」 を参照のこと。(MySQL 5.1.5 から導入したが、MySQL 5.1.15 で削除している。)

  • have_rtree_keys

    YESRTREE インデックスを利用できる場合。NO :そうでない場合。(MyISAM テーブルの空間インデックスで使用している。)

  • have_symlink

    YES : シンボリック リンク サポートを有効化している場合。NO : そうでない場合。Unix では DATA DIRECTORY および INDEX DIRECTORY のテーブル オプションを必要とする。Windows では、データ ディレクトリの symlink 関数を必要とする。

  • init_connect

    クライアント接続でサーバが実行する文字列。この文字列は 1 つ以上の SQL ステートメントから成る。複数のステートメントを指定するには、セミコロンで文字を区切る。たとえば、クライアントで自動コミット (autocommit) モードを有効にしていた場合に、クライアントでデフォルトとして開始する。自動コミットをデフォルトで無効にするグローバル変数は存在しないが、init_connect を使用すると、同様の効果を期待できる (複数のステートメントを指定する)。

    SET GLOBAL init_connect='SET AUTOCOMMIT=0';
    

    これの変数は、コマンドラインまたはオプション ファイルで設定できる。オプション ファイルで変数を設定するには、次のラインを使用する。

    [mysqld]
    init_connect='SET AUTOCOMMIT=0'
    

    ノート: init_connect の内容は SUPER 権限のあるユーザには通用しない。つまり、init_connect の誤値がクライアント接続を阻止しないようにしている。たとえば、シンタックス エラーを保持する値がステートメントにあると、クライアント接続に支障をきたす。SUPER 権限を持つユーザに対して init_connect を実行しないということは、ユーザとの接続と init_connect の値に対して害を与えないということである。

  • init_file

    サーバ起動時に、--init-file オプションで指定するファイルの名前。このファイルに起動時に実行する (したい) SQL ステートメントを組み込む。それぞれのステートメントを一行命令文として、コメントは入れないこと。

    ノート: --init-file オプションは、MySQL を --disable-grant-options オプションでコンフィギャしている場合には利用不可。詳細は 項2.9.2. 「典型的な configure オプション」 を参照のこと。

  • init_slave

    init_connect に類似する。SQL スレッドを開始するときにスレーブ サーバが実行する文字列。.この文字列の形式は init_connect と同一である。

  • innodb_xxx

    InnoDB システム変数は 項13.5.4. 「InnoDB 起動オプションとシステム変数」 を参照のこと。

  • interactive_timeout

    対話式接続を終了する前に、サーバがアクティビティを待機する秒数。対話型クライアントの定義は、mysql_real_connect()CLIENT_INTERACTIVE オプションを使用するクライアントのことである。wait_timeout も参照のこと。

  • join_buffer_size

    完全結合(インデックスを使用しない結合)に使用するバッファのサイズ。これにより、フル テーブル スキャンを実行できる。一般的には、結合を高速化する最良の方法は、インデックスを追加することである。しかし、インデックスを追加できない場合に、 join_buffer_size の値を大きくすると結合が速くなる (完全結合になる)。つまり、2 つのテーブル間の完全結合ごとにバッファを割り当てる。テーブル間の結合が複雑な場合は、複合バッファを必要とすることもある。

  • key_buffer_size

    MyISAM テーブルのインデックス ブロックをバッファし、すべてのスレッドで共有。key_buffer_size は、インデックス ブロックに使用するバッファのサイズである。キー バッファはキー キャッシュのこと。

    key_buffer_size の最大値は 4 GB 。物理 RAM、RAM 制限、オペレーティング システム、プラットフォームの状態などによるが、効果的な設定値としては、4 GB を下回る程度が良い。

    環境に応じて、インデックス処理 (すべての読み込みと複数の書き込み) を改善する目的で、この値を大きくできる。一般的には、マシンのメモリ使用率 25 % の値であることが好ましい。使用率の 50 % にすると、値が大き過ぎるため、システム処理が極端に遅くなる。MySQL のデータ読み込みのファイルシステムのキャッシュは OS に依存しているため、ファイル キャッシュ用にスペースに余裕を持たせることが必要である。別のストレージ エンジンの必要メモリに関しても検討のこと。

    同時書き込みが多い場合などに、スピードを上げるには、LOCK TABLES を使用する。詳細は 項6.2.16. 「INSERTステートメントの速度」 を参照のこと。

    キー バッファのパフォーマンスをチェックするには、SHOW STATUS ステートメントを発行し、Key_read_requestsKey_readsKey_write_requests、そして Key_writes の変数を調べる (項12.5.4. 「SHOW 構文」 を参照)。一般的には Key_reads/Key_read_requests の比率は、0.01 より小さいことが望ましい。操作がほとんど更新と削除だけの場合は Key_writes/Key_write_requests の比率は 1 に近い。同時に多くの行に影響を与える更新を行う場合や、DELAY_KEY_WRITE テーブル オプションを使用している場合には、より小さい比率になる。

    使用中のキー バッファのフラクション (破片) は、バッファ ブロック サイズと、key_buffer_sizeKey_blocks_unused を併用して決めることができる。これは、key_cache_block_size システム変数から利用可能。

    1 - ((Key_blocks_unused × key_cache_block_size) / key_buffer_size)
    

    これは近似値である。キー バッファのスペースによっては、管理ストラクチャに対して内部的に割り当てを行っているので、近似とする。

    MyISAM の複数キー キャッシュを作成することが可能である。サイズの上限は、4 GB で、グループごとではなく、キャッシュごとに適用する。詳細は 項6.4.6. 「MyISAMキーキャッシュ」 を参照のこと。

  • key_cache_age_threshold

    この値は、キー キャッシュの hot サブ チェーンから warm サブ チェーンへのバッファ降格を制御する。この値が小さいと降格は急激に起こる。最小値は 100。デフォルトは 300。詳細は 項6.4.6. 「MyISAMキーキャッシュ」 を参照。

  • key_cache_block_size

    キー キャッシュのブロック サイズをバイト単位 (byte)。 デフォルトは 1024 。詳細は 項6.4.6. 「MyISAMキーキャッシュ」 を参照のこと。.

  • key_cache_division_limit

    キー キャッシュのバッファ チェーンにおける hot と warm のサブ チェーン間のディビジョン ポイント (分岐点)。 この値は、warm のサブ チェーンに使用するバッファ チェーンのパーセンテージである。許容範囲は 1 から 100 まで。デフォルトは 100 。詳細は 項6.4.6. 「MyISAMキーキャッシュ」 を参照のこと。

  • language

    エラー メッセージに使用する言語。

  • large_file_support

    mysqld を大きなファイルをサポートするオプションでコンパイルしているかどうか (を指す)。

  • large_pages

    大きなページをサポートしている場合の戻値。

  • lc_time_names

    ロケールを指定する。これは月日、略語などを表示する言語を制御する。DATE_FORMAT()DAYNAME()MONTHNAME() などの関数からの出力に影響する。ローケル名は POSIX 標準で、'ja_JP' または 'pt_BR' などとする。デフォルトはシステムのローケル設定を問わず、'en_US' である。詳細は 項4.10.9. 「MySQL サーバのローケル サポート」 を参照のこと。(MySQL 5.1.12 で導入)

  • license

    サーバのライセンス タイプ (種類)

  • local_infile

    LOAD DATA INFILE ステートメントで、LOCAL をサポートしているかどうか (を指す)。詳細は 項4.6.4. 「LOAD DATA LOCAL のセキュリティ関連事項」を参照のこと。

  • locked_in_memory

    --memlock によるメモリのロックが mysqld で有効かどうか (を指す)。

  • log

    すべてのクエリのログを有効にしているかどうか (を指す)。項4.11.3. 「一般クエリ ログ」 を参照のこと。

  • log_bin

    バイナリ ログを有効にしているかどうか (を指す)。 項4.11.4. 「バイナリ ログ」 を参照のこと。

  • log_bin_trust_function_creators

    この値はバイナリ ログを有効化しているときに適用。Stored Function (関数) を作成するユーザが、 信用できない関数を作成する可能性を制御する。つまり、バイナリ ログへの書き込みに対して危険な関数を発行しないようにする。 この値を 0 (デフォルト) にする場合、CREATE ROUTINEALTER ROUTINE 権限のいずれかに加え、SUPER 権限を持たないユーザによる関数の作成 (置換) を許可しない。 0 にすると、その制限が強まり、DETERMINISTIC あるいは、READS SQL DATANO SQL のいずれかの特性を持った関数での宣言が必要になる。この値を 1 にすると、MySQL は関数に対して、このような制限はなくなる。詳細は 項17.4. 「ストアドルーチンとトリガのバイナリログ」 を参照のこと。

  • log_error

    エラー ログの位置。

  • log_output

    一般クエリ ログとスロー クエリ ログの出力先。TABLE (テーブルへのログ)、FILE (ファイルへのログ)、NONE (テーブルまたはファイルにログしない。) などを、複数の単語をカンマ区切りリストにできる。デフォルトは TABLENONE は、どの指定子よりも優先となる。つまり、NONE の場合、ログ エントリはログを有効化していても書き込みがない。ログを有効にしていなければ、log_outputNONE でなくても、ログできない。詳細は 項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 を参照のこと。(MySQL 5.1.6 から導入)

  • log_queries_not_using_indexes

    インデックスしていないクエリをスロー クエリ ログに記録しているかどうか (を指す)。詳細は 項4.11.5. 「スロー クエリ ログ」 を参照のこと。(MySQL 5.1.11 から導入)

  • log_slave_updates

    スレーブ サーバがマスタ サーバから受け取った更新を、スレーブ サーバ自身のバイナリ ログに記録するかどうかを指す。この効果を得る (スレーブでバイナリ ログする) には、スレーブ上でバイナリ ログを有効にしておく必要がある。項5.1.3. 「レプリケーションのオプションと変数」 を参照のこと。

  • log_slow_queries

    スロー クエリのログするかどうか (を指す)。「Slow」 は long_query_time の値で決定する。項4.11.5. 「スロー クエリ ログ」 を参照のこと。

  • log_warnings

    警告メッセージに追加情報を表示するかどうか (を指す)。デフォルトでは有効 (1) 。0 にすると無効になる。この値が1より小さい場合、接続を中断した情報をエラーログに出力できない。

  • long_query_time

    クエリでこの値(秒単位)より時間がかかると、Slow_queries カウンタが増える (increment)。--log-slow-queries オプションを使用している場合、クエリはスロー クエリ ログ ファイルでの記録になる。この値は、CPU 時間ではなく、リアル タイムである。したがって、低負荷のシステムではしきい値 (基準値) より下のクエリが、高負荷のシステムでしきい値より上になる場合がある。下限値は 1 で、デフォルトは 10。項4.11.5. 「スロー クエリ ログ」 を参照のこと。

  • low_priority_updates

    1 に設定すると、対象テーブルに影響する SELECT または LOCK TABLE READ を完了するまで、INSERTUPDATEDELETELOCK TABLE WRITE などのステートメントを待機させる。この変数の旧称は sql_low_priority_updates

  • lower_case_file_system

    データ ディレクトリのファイルシステムの大小文字区別を示す。OFF の場合は、ファイル名でこの区別をしていることを意味し、ON の場合は大小文字の区別をしていないことを意味する。

  • lower_case_table_names

    この値が 1 の場合、テーブル名を小文字変換で格納している。つまりテーブル名には大小文字の区別がないことを示す。この値が 2 の場合、テーブル名を入力通りに格納するが、小文字の区別をする。このオプションはデータベース名とテーブルのエイリアスで適用。項8.2.2. 「識別子の大文字/小文字区別」 を参照のこと。

    InnoDB テーブルを使用する場合、名前を強制的に小文字に変換するには、すべてのプラットフォームでこの値を 1 に設定する。

    たとえば、Windows または Mac OS などで、システムで MySQL を実行していて、ファイル名に大小文字の区別がない場合は、この値を 0 に しない こと。起動時などでこの値をまだ設定していない状態で、かつデータ ディレクトリのファイルシステムで大小文字の区別をしていないときには、MySQL が自動的に lower_case_table_names を 2 に設定する。

  • max_allowed_packet

    1 パケットの最大サイズ。または生成/中間文字列。

    パケット メッセージ バッファは net_buffer_length バイトで初期化するが、必要に応じて max_allowed_packet バイトまで大きくできる。デフォルト値は小さいが、大きな(不正)パケットを受けないように設定している。

    大きな BLOB カラムを使用している場合には、この値を大きくする必要がある。使用する最大の BLOB と同じ大きさにする。max_allowed_packet のプロトコル制限は 1GB。

  • max_binlog_cache_size

    複数ステートメントのトランザクションでこれより多くのメモリが必要になると、Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage というエラーが発生する。下限値は 4096 で、最大 (デフォルト) は 4 GB 。

  • max_binlog_size

    バイナリ ログ ファイルへの書き込みがログ ファイル サイズと干渉し、この値を超える場合、バイナリ ログをローテートする。(現行 ファイルを閉じて、次のファイルを開ける。) 設定可能値は、4096 バイト以上 1 GB (デフォルト) 以下。

    注意 : トランザクションではバイナリ ログへの書き込みを 1 つのまとまりとして処理するため、トランザクション自体を複数のバイナリ ログに分割することは絶対的にない。したがって、大きなトランザクションがある場合、バイナリログの max_binlog_size が大きくなることがある。

    max_relay_log_size が 0 の場合、max_binlog_size の値がリレー ログにも適用となる。

  • max_connect_errors

    ホストからの接続中断回数がこの値を越えた場合、それ以降、そのホストからの接続をブロックする。ブロックを解除するには、FLUSH HOSTS コマンドを使用する。

  • max_connections

    MySQL への最大同時接続数。MySQL 5.1.15 以降のデフォルトは150 (以前は 100)。詳細は 項B.1.2.6. 「Too many connections を参照のこと。

    MySQL Enterprise 警告:同時最大接続数を増加することには危険が伴います。MySQL Network Monitoring and Advisory Service では、max_connections に関するアドバイスを提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html () で参照してください。

    この値を増やすと、mysqld のファイルの記述子の数を増やすこととなる。ファイル記述子の制限に関するコメントは 項6.4.8. 「MySQL でのテーブルのオープンとクローズの方法」 を参照のこと。

  • max_delayed_threads

    INSERT DELAYED ステートメント処理に、スレッドがこの数に達すると処理しない。つまり、スレッドの最大数である。使用中の INSERT DELAYED スレッド後に、データを新規テーブルに挿入すると、その行は DELAYED 属性を指定していない行になる。値を 0 に設定すると、MySQL は DELAYED を処理するスレッドを 作成しなくなる。事実上、DELAYED を完全に無効にする。

  • max_error_count

    SHOW ERRORSSHOW WARNINGS で表示するエラーや警告の最大数。

  • max_heap_table_size

    MEMORY 型テーブルの最大メモリ サイズを設定する(ヒープ)。この変数の値で MEMORY テーブルの MAX_ROWS 値を計算する。この変数の設定は、既存の MEMORY テーブルには影響しない。ただし、CREATE TABLE などのステートメントで再生成したり、 ALTER TABLE または TRUNCATE TABLE で変更した場合は影響する。

    MySQL Enterprise MySQL Network Monitoring and Advisory Service では、max_heap_table_size の最適設定に関するアドバイス (推奨) を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

  • max_insert_delayed_threads

    max_delayed_threads に対するシノニム。

  • max_join_size

    max_join_size の値でクエリを制限する。長い時間をかけて百万行を返すような WHERE なしの結合を作成するようなユーザをいる場合にこの変数を設定すると、サーバへの無駄な負荷を軽減させることができる。(max_join_size 値を超える行数のレコードを読み取ろうとするとエラーになる。) SELECT ステートメントで、レコードの組み合わせ調べ (単一テーブルまたは複数テーブルに対するステートメント) がこの値を超える場合 や、またはこの値を超えるディスクシークの実行を許可しない。 この値を設定すると、キーの使用が不適切で長時間かかるような SELECT ステートメントを捕捉できる。

    この変数を DEFAULT 以外の値で設定すると、SQL_BIG_SELECTS の値が 0 にリセットになる。SQL_BIG_SELECTS 値を再び設定すると、max_join_size 変数は無視の対象になる。

    クエリ結果がクエリ キャッシュにある場合は、結果のサイズ チェックすることはなく、これは結果がすでに計算済みで、それをクライアントに送信することがサーバの負荷にならないためである。

    この変数の旧称は sql_max_join_size である。

  • max_length_for_sort_data

    使用する filesort アルゴリズムを決定するインデックス値の最大サイズ。項6.2.12. 「ORDER BY最適化」 を参照のこと。.

  • max_prepared_stmt_count

    サーバの Prepared ステートメントの合計数の最大値。この値で制限する。リクエスト応答を大量に発生させることで、サーバの応答機能の帯域を使い切るなど、いわゆる DoS攻撃 (denial-of-service attacks) を受ける可能性がある環境で使用する。デフォルト値は 16382。許容値は 0 から 100 万。この値が実行中の Prepared ステートメントの数より低い場合は、既存ステートメントが影響を受けることはなく、そのまま使用できるが、新規のステートメントに関しては、この制限値よりも現行数を低減するまで、準備できない。(MySQL 5.1.10 からの導入)

  • max_relay_log_size

    レプリケーション スレーブがリレー ログに書き込みをすると、カレント ログ ファイル サイズがこの変数値を越える原因になり、スレーブはリレー ログをローテートする。 (現行ファイルを閉じ、次のファイルを開ける。) max_relay_log_size を 0 とした場合、サーバはバイナリ ログとリレー ログの両方に max_binlog_size を使用する。max_relay_log_size が 0 より大きい場合、リレー ログのサイズを抑制し、両ログに異なるサイズを持たせることが可能になる。max_relay_log_size は 4096 バイトから 1GB 以内で設定するか、または 0 に設定する。デフォルト値は 0 。項5.5.1. 「レプリケーション実装の詳細」 を参照のこと。

  • max_seeks_for_key

    キーでレコード検索の最大回数を制限する。キー スキャンでテーブルからレコードを検索するときに、MySQL オプティマイザでキーの基数とは関係なく (無視して)、キー検索の回数をこの指定値までとする。項12.5.4.17. 「SHOW INDEX 構文」 を参照のこと。この値を低く(100 くらいに)設定すると、MySQL でののスキャンがテーブルではなくキーを優先するようになる。

  • max_sort_length

    BLOB 値または TEXT 値をソートするときに使用するバイト数。各値の最初の max_sort_length バイトだけを使用し、残りは無視になる。

  • max_sp_recursion_depth

    ストアド プロシージャが呼び出す回数。このオプションのデフォルト値は 0 で、ストアド プロシージャの再帰を完全に無効にする。

    この変数はグローバル、かつセッションごとの設定が可能。

  • max_tmp_tables

    1 つのクライアントが同時に開けたままにできるテンポラリ テーブルの最大数。(このオプションはまだ利用できない。)

  • max_user_connections

    単一ユーザ (MySQL アカウント) が同時に接続できる最大数。値 0 は 「制限なし」 という意味。

    この値はグローバル スコープとセッション スコープ (読み込みオンリー) の両方を持つ。 セッション値は通常グローバル値と同じ値。ただし、 セッション ユーザが 0 以外の MAX_USER_CONNECTIONS 値を持ってる場合には、このセッション値がアカウント制限にも反映する。

  • max_write_lock_count

    この回数の書き込みロックをした後に、読み取りロックを許可する。(ロックが必要なほど大量のテーブル書き込みがある場合など)

  • multi_range_count

    テーブル ハンドラへ一括送信できる最大許容範囲 (範囲選択時)。デフォルトは256。複数の値域をハンドラへ 1回で送れると、一定の選択において劇的なパフォーマンス向上になる。これは NDB Cluster のテーブル ハンドラで非常に有用で、値域要求をすべてのノードへ送るときに役に立つ。要求のバッチを一度に送ることは、通信コストを大幅節減に繋がる。

  • myisam_data_pointer_size

    CREATE TABLE 時に、MAX_ROWS オプションを指定していないときの MyISAM テーブル内部のポインタ サイズを指定する。(テーブルの最大物理サイズの決定。) 変数は 2 以上 7 以下である必要がる。デフォルトでは 6。項B.1.2.11. 「The table is full を参照のこと。

  • myisam_max_extra_sort_file_size (廃止)

    ノート:この変数は MySQL 5.1 ではサポートしていない。詳細は MySQL 5.0 Reference Manual を参照のこと。

  • myisam_max_sort_file_size

    REPAIR TABLEALTER TABLELOAD DATA INFILEなどを使用して MyISAM インデックスを再生成するときに、MySQL が使用できるテンポラリ ファイルの最大サイズ。ファイル サイズがこれより大きい場合、インデックスはキー キャッシュでの作成になる(時間がかかる)。値の単位はバイト。

    デフォルトでは 2GB 。MyISAM インデックス ファイルがこのサイズを越え、ディスク容量が要るようになるときには、この値を大きくするとパフォーマンス向上になる。

  • myisam_recover_options

    --myisam-recover オプションの値。項4.2.2. 「コマンド オプション」 を参照のこと。

  • myisam_repair_threads

    この値が 1 より大きい場合、Repair by sorting の修復プロセスでの MyISAM テーブル インデックスは並列での作成になる。インデックス毎のスレッド生成になる。

    ノート:複数スレッドの修復は ベータ段階 です。

  • myisam_sort_buffer_size

    REPAIR TABLE 文実行時に MyISAM テーブルのインデックスをソートする場合、または CREATE INDEXALTER TABLE などでインデックスを作成する場合に、割り当てるバッファのサイズ。

  • myisam_stats_method

    MyISAM テーブルでインデックス分布統計を集計するとき、サーバの NULL 値の扱いを決定する。この変数の値は nulls_equal または nulls_unequal のどちらか。nulls_equal の場合、すべての NULL インデックス値を同等として扱い、 NULL 値の数とサイズが同等の単値のグループを生成する。nulls_unequal の場合、NULL の値同士を同等とは扱わず、それぞれの NULL で、サイズを 1 とする独特のグループを生成する。

    この方法で、クエリの実行に対して、オプティマイザがインデックスを選択するときに影響を受けるテーブルの統計を取る。詳細は 項6.4.7. 「MyISAMインデックス統計コレクション」 を参照のこと。

  • myisam_use_mmap

    MyISAM テーブルの読み書き込みで使用するメモリ マッピング。(MySQL 5.1.4 での追加)

  • multi_read_range

    範囲指定の SELECT 文を発行するときに、ストレージ エンジンに送ることができる範囲の最大値を指定する。デフォルトでは 256。 複数の範囲指定をストレージ エンジンに送ることは 特定の SELECT 文に対して、特に NDBCLUSTER において、大幅にパフォーマンスを改善する。

  • named_pipe

    サーバが名前付きパイプ (named pipes) を経由した接続をサポートするかどうか。Windows 専用。

  • ndb_autoincrement_prefetch_sz

    auto_increment カラムにおけるギャップの確率 (probability) を決定する。1 にセットした場合、これを最小限に抑える。最適化を目的として値を大きくする設定すると、? が挿入を高速化するが、バッチ挿入に使用する自動インクリメントの数が減る可能性がある。デフォルトは 32。下限値は 1.

  • ndb_cache_check_time

    NDB のクエリ キャッシュをチェックする前に待機するミリ秒 (msec)。この値を 0 (デフォルト) に設定すると、NDB クエリ キャッシュでクエリ毎のバリデーションを行う。

    推奨最大値は 1000 で、クエリ キャッシュが一秒間に一度のチェック対象になることを意味する。値が大きくなるということは、NDB のクエリ キャッシュのチェック回数が減り、別のmysqld での更新が原因で、バリデーションが無効化することを意味する。この値を 2000 以上に設定しないこと。

  • ndb_extra_logging

    デバッグやトラブルシューティング用に追加の NDB ロギングを行うには、ゼロではない値を設定する。デフォルトは 0

    (MySQL 5.1.6 での追加)

  • ndb_force_send

    NDB へ迅速にバッファを送るよう命令する。他のスレッドを待機しない。デフォルトは ON

  • ndb_index_stat_cache_entries

    統計の精度を設定する。開始キーと終了キーの数を決め、統計メモリ キャッシュに格納する。ゼロはキャッシュしていないことを示し、その場合には、データ ノードが直接的にクエリになる。デフォルトは 32.

  • ndb_index_stat_enable

    NDBインデックス統計。クエリの最適化。デフォルトでは ON

  • ndb_index_stat_update_freq

    統計キャッシュの代わりにデータ ノードにクエリを行うかを示す回数。たとえば、値が 20 の場合、クエリ 20 毎に、データ ノードを渡すという意味。

  • ndb_report_thresh_binlog_epoch_slip

    binlog ステータスをレポートするまでに、遅れるエポック数の閾値。たとえば、値が 3 (デフォルト) であった場合、ストレージ ノードから受けたエポックと 3 以上の binlog に適用したエポックの数が異なるときに、ステータス メッセージをクラスタ ログする。

  • ndb_report_thresh_binlog_mem_usage

    binlog ステータスをレポートするまで残っている空きメモリのパーセンテージの閾値。たとえば、値が 10 (デフォルト) であった場合、データ ノードから受ける binlog データに使うメモリが 10% 降下するという意味。そしてステータス メッセージをクラスタ ログにする。

  • ndb_use_copying_alter_table

    NDB で、オンラインの ALTER TABLE 操作で、問題が発生したテーブルをコピーするために使用する。デフォルトは OFF になっている。

    (MySQL 5.1.12 での追加)

  • ndb_use_exact_count

    SELECT COUNT(*) クエリの高速化を図るときに、レコードの回数を適用するよう NDB に命令する。デフォルトでは ON になっている。全体的にクエリを速度化するには、これを無効にする。つまり、ndb_use_exact_countOFF にする。

  • ndb_use_transactions

    NDB トランザクションを OFF に設定することで無効にできるが、これは極力やらない。デフォルトでは ON になっている。

  • net_buffer_length

    クライアント スレッドが接続バッファと結果バッファに関連付けられている。両者は net_buffer_length で与えられたサイズで始まるが、必要に応じて、max_allowed_packet バイトまで劇的に拡大できる。結果バッファは SQL 文毎に net_buffer_length まで縮小する。

    この値はできるだけ変更しない。ただし、メモリが非常に限られている環境において、この値をクライアントから送信されるステートメントの長さに合わせて設定できる。ステートメントがこの長さを越えた場合、接続バッファは自動的に拡大する。net_buffer_length の最大値は 1MB に設定できる。

  • net_read_timeout

    読み込みを中断するまでデータ追加を待機する秒数。タイムアウトは TCP/IP 接続にだけ適用する。これは Unix のソケット ファイル、または名前付きパイプ、共有メモリなどを経由していない接続のことである。サーバがクライアントからの読み込みを行うとき、net_read_timeout のタイムアウト値が中断するタイミングを制御する。書き込みを行うときは、net_write_timeout のタイムアウト値が中断するタイミングを制御する。slave_net_timeout のセクションも参照のこと。

  • net_retry_count

    通信ポートでの読み込みが中断した場合に、実行できる再試行回数。FreeBSD でこの値を大きくすると、内部中断をすべてのスレッドに通知する。

  • net_write_timeout

    書き込みを中断するまで、ブロック書き込みを待機する秒数。タイムアウトは TCP/IP 接続にだけ適用する。これは Unix のソケット ファイル、または名前付きパイプ、共有メモリなどを経由していない接続のことである。net_read_timeout も参照のこと。

  • new

    MySQL 4.0 において、MySQL 4.1と同様の動作 (下位互換性)をするかどうか (を指す)。MySQL 5.1 では、この値は常に OFF

  • old_passwords

    サーバが MySQL 4.1より前で使用しているパスワード形式を採用するかどうか (を指す)。項B.1.2.3. 「Client does not support authentication protocol を参照のこと。

  • one_shot

    これは変数ではない。しかし、特定の変数を設定するときに使用できる。詳細は 項12.5.3. 「SET 構文」 を参照のこと。

  • open_files_limit

    mysqld が開けるオペレーティング システムのファイル数。これはシステムで指定されている実際の値であり、起動時のパラメータとして --open-files-limit オプションで mysqld または mysqld_safe に指定したものとは異なる場合がある。MySQL がオープンファイル数を変更できないシステムでは 0 になる。

  • optimizer_prune_level

    ヒューリスティックス (経験則) を採用したクエリ最適化を制御し、オプティマイザの検索スペースからあまり見込みのない、部分的なプランをパージ (削除) する。値を 0 にすると、ヒューリスティックスを無効化し、オプティマイザは完全な検索を行う。値を 1 にすると、オプティマイザは中間プラン (intermediate plans) で検索したレコード数に基づいてプランを削除する。

  • optimizer_search_depth

    クエリ オプティマイザが実行する検索深さの最大値を指定する。クエリ結果の関係数が大きい値の場合は、プランよりも良いということを示すが、クエリの実行プラン生成に時間がかかる。関係数が小さい値の場合は、より速い実行プランを返すが、結果プランが最適であるとは言えない。値を 0 した場合、システムは自動的に妥当な値を計算する。値をクエリに使用しているテーブルの最大値に + 2 した場合は、オプティマイザが検索を実行するときに、MySQL 5.0.0 (と前バージョン) で使用したアルゴリズムに切り替える。

  • pid_file

    プロセス ID (PID) ファイルのパス。--pid-file オプションで設定する。

  • plugin_dir

    プラグイン ディレクトリのパス。(MySQL 5.1.2 での追加)

  • port

    mysqldサーバが利用するTCP/IPポート番号。--port オプションで設定する。

  • preload_buffer_size

    インデックスをプレロードするときに割り当てるバッファ サイズ。

  • prepared_stmt_count

    準備されたステートメント (prepared statements) の現在値。max_prepared_stmt_count システム変数で与えるステートメントの最大値。MySQL 5.1.10 からの追加で、MySQL 5.1.14 では、 Prepared_stmt_count グローバル ステータス変数に変換していた。

  • protocol_version

    MySQL サーバが使うクライアント/サーバ間のプロトコル バージョン。

  • query_alloc_block_size

    クエリの解析や実行で生成するオブジェクトに割り当てるメモリ ブロックの割り当てサイズ。メモリのフラグメントに問題がある場合、これを少し大きくすると改善できる可能性がある。

  • query_cache_limit

    この値より大きい結果はキャッシュしない。デフォルトは 1MB。

  • query_cache_min_res_unit

    クエリ キャッシュで割り当てるブロックの最小サイズ (バイト単位)。デフォルトは 4096(4KB)。この変数を利用した効果については、項4.13.3. 「クエリ キャッシュの設定」 を参照のこと。

  • query_cache_size

    古いクエリの結果の保存用に割り当てたメモリ (クエリ キャッシュで確保するメモリ)。 この値を 0 (デフォルト) にすると、クエリ キャッシュは無効化する。許容値は 1024 の倍数。値はすべて、近似の倍数で端数を切り捨てる。ノート: query_cache_size バイトのメモリは、query_cache_type が 0 で設定してあっても、割り当ての対象となる。詳細は 項4.13.3. 「クエリ キャッシュの設定」 を参照のこと。

  • query_cache_type

    クエリ キャッシュを行う条件を指定する。GLOBAL 値に設定すると、これ以降に接続するすべてのクライアントの条件が反映する。それぞれのクライアントで SESSION 値を設定することができ、これはマシン レベルでのクエリ キャッシュに影響する。次のテーブルは数値を示す。

    オプション説明
    0 または OFFキャッシュを使用しない。注意:これはクエリ キャッシュのバッファの割当を解除しない。解除するには query_cache_size を 0 にセットする。
    1 または ONSELECT SQL_NO_CACHE を除くすべての結果をキャッシュする。
    2 または DEMANDSELECT SQL_CACHE で始まるクエリだけをキャッシュする。

    この変数のデフォルトは ON

  • query_cache_wlock_invalidate

    通常、クライアントが MyISAM テーブルの WRITE ロックを獲得する場合、別のクライアントはクエリの結果がキャッシュ内にあるときは、そのテーブルへのクエリ発行をブロックしない。この値を 1 にした場合、テーブルに対する WRITE ロックを得ることとなり、そのテーブルに対するクエリ キャッシュのクエリは無効化する。これにより、テーブルへのアクセスを試みるクライアントに対して、ロック有効中は待機するよう抑制できる。

  • query_prealloc_size

    クエリの解析および実行に使用する永続バッファ サイズ。このバッファはクエリ間でも開放しない。頻繁に複雑なクエリを発行する場合、query_prealloc_sizeの値を大きくして、クエリ実行時のメモリ割り当て回数を減らすことになるため、パフォーマンスを改善できる可能性がある。

  • range_alloc_block_size

    範囲の最適化で割り当てるブロックのサイズ。

  • read_buffer_size

    順次スキャン (全件) を行うときに各スレッドが割り当てるバッファ サイズ。バイトで指定する。このスキャンを何度も行う場合には、この値を大きくする。デフォルトは 131072。

  • read_only

    レプリケーション スレーブ サーバで、この値を ON に設定すると、サーバが SUPER 権限を持つユーザ以外からの更新ができない。スレーブ サーバにおいては、マスタ サーバからの更新だけを許容し、クライアントからの要求を無視するようなる。この動作は TEMPORARY テーブルには使えない。

    read_onlyGLOBAL 変数として存在するために、SUPER 権限が必要な値への変更になる。マスタ サーバで read_only に変更すると、スレーブ サーバで複製できなくなる。この値は、マスタの設定とは独立しているスレーブ サーバで行う。

    MySQL 5.1.15 以降は、次のことに注意する。

    • read_only を有効にしようとするときに、明示的なロック (LOCK TABLESなどから) がある場合、または未処理のトランザクションがある場合は、エラーになる。

    • 別のクライアントに明示的なテーブル ブロックがある場合、または未処理のトランザクションがある場合に、read_only を有効にすると、ロックをリリースし、トランザクションが完了するまでブロックする。read_only にする試みが進行中である場合、テーブル ロックに対する別のクライアントからの要求、またはトランザクションを開始することへの要求を、read_only の設定を完了するまで、ブロックする。

    • read_only はグローバル読み込みブロック (FLUSH TABLES WITH READ LOCK などから) を保持している間に有効化できる。これはテーブル ロックを巻き込まないためである。

  • read_rnd_buffer_size

    ソートしたレコードを読み出すときのバッファサイズを指定する。ディスク検索を行わないように、レコードをこのバッファから読み取る。この値を大きく設定すると、ORDER BY のパフォーマンスを大幅に向上できる。しかし、これはスレッド固有の変数であるため、これをグローバル値を大きな値で設定すべきではない。したがって、大量のクエリを実行するときにだけ、クライアント内のセッション値を変更する。

  • relay_log_purge

    リレー ログ ファイルが不必要になったときの自動削除フラグを設定する。デフォルトは 1 (ON)。

  • rpl_recovery_rank

    この変数は使用していない。

  • secure_auth

    --secure-auth オプションを付けて MySQL サーバを起動する場合、MySQL サーバは古い形式 (4.1 より前) のパスワードを認証しない。 このときの値は ON (ブロック)。接続をブロックしないようにするには、OFF にする。

    これによりネットワーク セキュリティが不安定な場合など、古い形式を採用しているパスワードでの接続を許可しないようにするには、このオプションを有効にする。

    このオプションを有効にしたときに、権限テーブルが 4.1 よりも前の形式である場合には、起動時にサーバ エラーが発生する。 項B.1.2.3. 「Client does not support authentication protocol を参照のこと。

  • server_id

    サーバ ID 。--server-id オプションで設定する。これはレプリケーションを行うときなどに、マスタとスレーブのサーバ間でお互いを一意的に認識させるために使用する。

  • shared_memory

    共有メモリに付ける識別子を指定する。Windows 専用。

  • shared_memory_base_name

    共有メモリ接続で使用する共有メモリの名前。 このオプションはWindowsで有効。複数の MySQL インスタンス (サーバ) を一台のマシンで使用している場合に便利。デフォルト名は MYSQL。この名前は大文字と小文字を区別する。

  • skip_external_locking

    OFFmysqld が外部ロックを使用している場合。ON : 外部ロックが無効の場合。

  • skip_networking

    ON : サーバがローカル接続のみを許可する場合 (非 TCP/IP)。Unix では、ローカル接続に Unix ソケット ファイルを使用。Windows では、名前付きパイプまたは共有メモリを使用。NetWare では、TCP/IP 接続をサポートしている場合のみ。そのため、この変数を ON に設定してはいけない。この変数を ON にするには、--skip-networking オプションを使用する。

  • skip_show_database

    SHOW DATABASES 権限を持たずして SHOW DATABASES を使用するユーザにデータベースを表示しない。これは、他人のユーザ権限のデータベースを表示しないため、セキュリティの向上に役立つ。この効果は SHOW DATABASES 権限の設定オプションに依存する。値を ON にした場合、SHOW DATABASES ステートメントは SHOW DATABASES 権限を持つユーザにだけが使用でき、ステートメントにはすべてのデータベース名を表示する。値を OFF にした場合、SHOW DATABASES はすべてのユーザに対してこのステートメントの発行を許可するが、ユーザがSHOW DATABASES などの権限を持っているデータベースだけの表示になる。

  • slave_compressed_protocol

    マスタとスレーブの両方が圧縮プロトコルをサポートしているかどうか (を指す)。

  • slave_load_tmpdir

    スレーブサーバがレプリケーション データ ( LOAD DATA INFILE ステートメント) を読み込むときに 使用するテンポラリ ディレクトリのパスを指定する。

  • slave_net_timeout

    読み込みを中断するまで、マスタ/スレーブ接続からのデータを待機する秒数。タイムアウトは TCP/IP 接続にだけ適用。Unix ソケット ファイルを介した接続や、名前付きパイプ、共有メモリには適用しない。

  • slave_skip_errors

    スレーブがスキップ (無視) するレプリケーション エラー。

  • slave_transaction_retries

    InnoDB デッドロック、InnoDBinnodb_lock_wait_timeout、NDBCluster の TransactionDeadlockDetectionTimeout または TransactionInactiveTimeout を越えた場合、レプリケーション スレーブの SQL スレッドはトランザクションの実行に失敗する。そのときに、エラーで停止する前に、自動試行する回数のことを slave_transaction_retries 回と定義する。デフォルトでは 10 回。

  • slow_launch_time

    スレッドの作成にこの値(秒単位)より時間がかかると、サーバが Slow_launch_threads ステータス変数 (カウンタ) をインクリメントする。

  • slow_query_log

    スロー クエリ ログが有効になっているかどうか (を指す)。値が 0 (または OFF) の場合、ログしない。値が 1 (または ON) の場合、ログする。デフォルトは --log-slow-queries オプションを設定しているかどうかによる。ログ出力先は log_output システム変数で制御する。値を NONE にした場合、ログできるようにしていても、ログ エントリを書き込まない。slow_query_log は MySQL 5.1.12 からの導入。

  • slow_query_log_file

    スロー クエリ ログ ファイルの名前。デフォルトは host_name-slow.log 。初期値は --log-slow-queries オプションで変更可能。(MySQL 5.1.12 での追加)

  • socket

    Unix 環境で、ローカル接続に使用するソケット ファイル パス。デフォルトは /tmp/mysql.sock になっている。配布用の形式によっては、ディレクトリが異なる場合がある。たとえば、 RPM の /var/lib/mysql など。

    Windows環境では、ローカル接続に使用する名前付きパイプ名のこと。デフォルトは MySQL 。文字の大小区別なし。

  • sort_buffer_size

    ソートを実行する必要のあるスレッドがこのサイズのバッファを割り当てる。ORDER BY または GROUP BY などの操作を速くするには、この値を大きくする。 項B.1.4.4. 「Where MySQL Stores Temporary Files」 を参照のこと。

  • sql_mode

    現在のSQLモード。この値は動的に変更することが可能。項4.2.6. 「SQL モード」 を参照のこと。

  • sql_slave_skip_counter

    スレーブ サーバが無視するマスタからのイベント数。項12.6.2.6. 「SET GLOBAL SQL_SLAVE_SKIP_COUNTER 構文」 を参照のこと。

  • ssl_ca

    SSL CA 証明をリストしたファイルのパス。(MySQL 5.1.11 での追加)

  • ssl_capath

    SSL CA 証明書 (PEM形式) があるディレクトリへのパス。(MySQL 5.1.11 での追加)

  • ssl_cert

    セキュリティ上、安全に接続を確立するために使用する SSL 証明書。(MySQL 5.1.11 での追加)

  • ssl_cipher

    SSL 暗号化に使用するサイファ (暗号鍵) のリスト。サイファ リストは openssl ciphers コマンドと同形式。(MySQL 5.1.11 での追加)

  • ssl_key

    セキュリティ上、安全に接続を確立するために使用する SSL キー ファイル名。(MySQL 5.1.11 での追加)

  • storage_engine

    デフォルトのストレージ エンジン (テーブル タイプ)。サーバ起動時にストレージ エンジンを設定するには、--default-storage-engine オプションを使用する。項4.2.2. 「コマンド オプション」 を参照のこと。

  • sync_binlog

    この値が正数の場合、MySQL サーバはバイナリ ログへこの sync_binlog 回書き込みを行い、それごとにディスクへ同期する (fdatasync() を使用)。オートコミットモードでは、一つの SQL 文を発行毎に、ログ書き込みとなる。それ以外のモードでは、トランザクションごとの書き込みになる。デフォルト値は 0 で、ディスクへの同期は行わないことを示す。値を 1 にすると、最も安全な設定となる。これはクラッシュした場合などに失うものが、1 ステートメントあるいは1 トランザクションに留まるためである。しかし、これはパフォーマンスを遅くするため、対応策としては、同期を高速化するために、バッテリ バックアップ式キャッシュをディクスに持たせるなどする。

    sync_binlog 値の 0 (デフォルト) は、追加フラッシュは行わないことを示す。これはフラッシュが OS に依存する。

  • sync_frm

    値を 1 とした場合に、テンポラリ以外のテーブルを作成すると、.frm ファイルを ディスクへ同期する (fdatasync() を使用)。これは処理スピードを遅くするが、クラッシュに対して安全である。デフォルトは 1。

  • system_time_zone

    サーバ システムのタイム ゾーン。サーバが起動するときは、マシンのデフォルトタイムゾーンを継承する。これは サーバを起動したユーザアカウントの環境やスタートアップ スクリプトのオプションなどで変更可能。値は system_time_zone を設定する。通常、タイム ゾーンは TZ 環境変数で指定する。または mysqld_safe スクリプトでの --timezone オプションでも指定可能。

    system_time_zonetime_zone は別物である。両者の値は同値であることもあるが、後者はクライアント接続毎にタイムゾーンを初期化する変数である。項4.10.8. 「MySQL サーバのタイム ゾーン サポート」 を参照のこと。

  • table_cache

    MySQL 5.1.3 前まで、table_open_cache と呼ばれていた。 MySQL 5.1.3 以降は table_open_cache を使用する。

  • table_definition_cache

    定義キャッシュに保存できるテーブル定義数。テーブル数が多い場合に、テーブルを開けるスピードを速めるために、大きなテーブル定義キャッシュを作成できる。通常のテーブル キャッシュと比較すると、テーブル定義キャッシュが必要とするスペースが小さく、ファイル記述子を使用しない。(MySQL 5.1.3 以降)

  • table_lock_wait_timeout

    テーブル レベル ロックで待機する時間 (秒) を指定する。デフォルトのタイムアウトは 50 秒。タイムアウトは接続でカーソルを開けるとアクティブになる。SUPER 権限を保持していれば、ランタイムにグローバル設定可能。

  • table_open_cache

    すべてのスレッドに対するオープン テーブルの数 (キャッシュする最大テーブル数)。この値を大きくするということは、mysqld が要求するファイル記述子の数を増やすということ。Opened_tables ステータス変数をチェックしてテーブル キャッシュを増やす必要があるかどうかを調べる。項4.2.5. 「ステータス変数」 を参照のこと。Opened_tables の値が大きく、FLUSH TABLES を頻繁に行わない場合 (単にテーブルの開閉を強制するだけ)、table_open_cache 変数の値を増やす必要がある。テーブル キャッシュに関する詳細は 項6.4.8. 「MySQL でのテーブルのオープンとクローズの方法」 を参照のこと。MySQL 5.1.3 前には、table_cache と呼ばれていた。

  • table_type

    storage_engine のシノニム。MySQL 5.1 では storage_engine を使用。MySQL 5.2 では、table_type は削除されている。

  • thread_cache_size

    再利用のためにキャッシュ可能なスレッド数。クライアントが接続を切断したときに、以前のスレッド数が thread_cache_size 以下であれば、そのクライアントのスレッドはキャッシュに入る。新しいスレッドはすべてキャッシュから取り込まれ、キャッシュが空の場合のみ、新しいスレッドが作成される。新しい接続が多く発生する場合、この変数を大きくすることによりパフォーマンスを向上できる (スレッド実装が既に理想的な状態であれば、それほどパフォーマンスは向上しない)。Connections および Threads_created などのステータス変数の差異を調べると、スレッド キャッシュの効率性を確認できる。詳細は 項4.2.5. 「ステータス変数」 を参照のこと。

  • thread_concurrency

    Solaris では、mysqld がこの値を伴う thr_setconcurrency() を呼び出す。アプリケーションに、同時に実行する理想的なスレッド数を提供する。

  • thread_stack

    各スレッドのスタック サイズ。crash-me で検出する制限の多くは、この値に依存する。通常の操作ではデフォルト (192 KB) で十分である。項6.1.4. 「MySQL ベンチマークスィート」 を参照のこと。

  • time_format

    この変数は実装していない。

  • time_zone

    現在のタイムゾーン。この変数はクライアント接続毎にタイム ゾーンを初期化する。デオフォルトは 'SYSTEM' 、つまり system_time_zoneの値を使う」 ということ。サーバ起動時に --default-time-zone オプションで明示的に指定できる。項4.10.8. 「MySQL サーバのタイム ゾーン サポート」 を参照のこと。

  • timed_mutexes

    InnoDB ミューテックスをカウントしているかどうかを制御する。この値を 0 または OFF (デフォルト) に設定すると、ミューテックス カウントは無効になる。この値を 1 または ON に設定すると、ミューテックス カウントは有効になる。このカウントを有効にすると、SHOW ENGINE INNODB MUTEX からの出力の os_wait_times 値は、OS が待機した回数 (ms) を示す。それ以外では、この値は 0 である。

  • tmp_table_size

    メモリ内のテンポラリ テーブルの最大サイズ。実際の限度は max_heap_table_sizetmp_table_size の値より小さい値になる。メモリ内テンポラリ テーブルが制限値を超えると、MySQL はこれを自動的にディスク内の MyISAM テーブルにする。高度な GROUP BY クエリを展開する場合にメモリが沢山あるときは、 tmp_table_size (必要に応じて、max_heap_table_size も) の値を増やす。

  • tmpdir

    テンポラリ ファイルとテンポラリ テーブルのディレクトリ。この変数はラウンド ロビン式の複数のパスのリストをセットするときに使用する。Unix で、パスはコロン (‘:’) で区切り、Windows、NetWare、OS/2 などではセミコロン (‘;’) で区切る。

    複数ディレクトリ機能は、物理ディスク間で負荷を分担するときに使用する。MySQL サーバが レプリケーション スレーブである場合、tmpdir を使用して、メモリ ベースのシステムファイルまたはサーバ ホスト (OS) 再起動時に内容が消去されるディレクトリを指定しない。これは、レプリケーション スレーブが、マシンがリブートした場合や LOAD DATA INFILE 文の処理中であった場合などに対応するために、テンポラリのテーブルやファイルを必要とするため。もしこのディレクトリからテンポラリ ファイルが消えた場合は、サーバ再起動時にレプリケーション エラーが発生する。しかし、MySQL 4.0.0 以降を使用している場合は、slave_load_tmpdir 変数を使用して、スレーブのテンポラリ ディレクトリを設定できる。その場合、スレーブは通常の tmpdir 値を使用しないので、tmpdir を適切な (非永続的) 位置に設置する (スレーブサーバはこのパスを使用することになる)。

  • transaction_alloc_block_size

    メモリ ブロックの割り当てサイズ (byte)。 このメモリは、コミットするときにバイナリログへ書き込むための トランザクション内クエリを保存するために使用する。transaction_prealloc_size の説明を参照のこと。

  • transaction_prealloc_size

    永続的バッファの (初期) サイズをtransaction_prealloc_size と呼ぶ。メモリが不十分が原因で、このプール (領域) で割り当てが十分に行えない場合、transaction_alloc_block_size でプールの値を大きくする。トランザクションが済むと、プールは transaction_prealloc_size バイトで切り捨てになる

    単一トランザクション内のすべてのクエリをバッファ内に収めるように、transaction_prealloc_sizeを大きくすると、malloc() システム コールを避けることができる。

  • tx_isolation

    基準にするトランザクション隔離レベル。 デフォルト値は REPEATABLE-READ

    この変数は SET TRANSACTION ISOLATION LEVEL ステートメントで設定する。項12.4.6. 「SET TRANSACTION 構文」 を参照のこと。tx_isolation を直接、隔離レベル名に設定する場合に、スペースを含むときには、その名前を引用符で囲み、そのスペースをダッシュと置換する。たとえば、

    SET tx_isolation = 'READ-COMMITTED';
    
  • updatable_views_with_limit

    更新の許可するかどうかを制御する。ビューに基準テーブルで定義したプライマリ キーのすべてのカラムが含まれていない場合に、更新ステートメントで LIMIT 節を含んでいたら、そのビューを更新するかどうか、ということである。このような更新は GUI ツールなどから生成される。ここでの更新は UPDATE または DELETE ステートメントのこと。ここでのプライマリ キーとは PRIMARY KEY または UNIQUE インデックスのことで、NULL をカラムに含まない。

    この変数の値は 2 種類ある。

    • 1 または YES:エラー メッセージではなく、警告だけを発行。(デフォルト値)

    • 0 または NO:更新禁止。

  • version

    サーバのバージョン番号。

  • version_comment

    configure スクリプトには、MySQL を構築するときにコメントを指定できる --with-comment オプションがある。そのコメントの値。

  • version_compile_machine

    マシンのタイプ、または MySQL構築時のアーキテクチャ。

  • version_compile_os

    MySQL構築時のオペレーティング システムのタイプ。

  • wait_timeout

    対話式ではない接続 (反応の無い接続) を終了する前に、サーバがアクティビティを待機する秒数。このタイムアウトは TCP/IP 接続と Unix のソケット ファイル接続だけに適用。名前付きパイプと共有ファイルの接続には使用できない。

    スレッド起動時に、セッション wait_timeout 値は、wait_timeout グローバル値、または interactive_timeout グローバル値で初期化するが、これはクライアントのタイプによる。(CLIENT_INTERACTIVE の接続オプションを mysql_real_connect()) に定義する。) interactive_timeout の説明も参照のこと。

4.2.4. システム変数の使用

mysql サーバは、様々なシステム変数を保有し、その変数をどのように設定したかを示します (項4.2.3. 「システム変数」 を参照のこと)。それぞれのシステム変数にはデフォルト値があります。システム変数はサーバ起動時に、コマンドラインまたはオプション ファイルなどを使用してセットできます。大抵の場合、SETコマンドを使用して実行中のサーバで動的に変更できます。つまり、サーバを停止または再起動せずに変更できます。プログラミング式でシステム変数の値を参考にしてください。

サーバには 2 種類のシステム変数があります。グローバル変数はサーバの全体的なオペレーションに影響し、セッション変数はそれぞれのクライアント接続でのオペレーションに影響します。与えられた変数はグローバルとセッション、両方の値を持つこともあります。グローバルおよびセッション変数は次のように関係しています。

  • サーバが起動するとき、すべてのグローバル変数をデフォルト値に初期化する。このデフォルト値はコマンド ラインまたはオプション ファイルなどで指定できる。オプションに関しては、項3.3. 「プログラム・オプションの指定」 を参照のこと。

  • サーバにはクライアントが接続するセッション変数の組み合わせがある。クライアントのセッション変数は、グローバル変数に呼応するカレント値を使用して接続タイムで初期化する。たとえば、クライアントの SQL モードは、セッション sql_mode 値で制御し、クライアントが sql_mode のグローバル値に接続するときに初期化する。

システム変数はサーバ起動時にコマンドラインまたはオプションファイルを使用してグローバル設定できます。起動オプションを使用して値を設定するときは、数値を使用し、値には K (キロバイト)、M (メガバイト)、G (ギガバイト) などのサフィックスで与えます (大文字あるは小文字)。これらは、1024、10242 または 10243 の倍数を示します。これにより、次のコマンドは、クエリ キャッシュ サイズが 16 メガバイト、最大パケット サイズが 1 ギガバイトでサーバが起動することを示します。

mysqld --query_cache_size=16M --max_allowed_packet=1G

オプション ファイル内では、次のように設定します。

[mysqld]
query_cache_size=16M
max_allowed_packet=1G

サフィックスの大文字、小文字の区別は問わず、16M16m1G1g を同等とします。

SET ステートメントでラインタイムに設定できる変数の最大値を制限する場合には、サーバ起動時に --maximum-var_name=value のオプションで最大値を指定します。たとえば、query_cache_size の値がラインライムで 32 MB を超えないようにするには、--maximum-query_cache_size=32M とします。

システム変数は動的で、SET ステートメントでサーバ稼動中に変更できます。リストは 項4.2.4.2. 「動的システム変数」 を参照してください。SET でシステム変数を変更するには、var_name とし、オプション的に修飾子で先行します。

  • 変数がグローバルであることを明示するには、GLOBAL または @@global. で名前を先行する。グローバル変数を設定するには SUPER 権限が必要。

  • 変数がセッションであることを明示するには、SESSION@@session.@@ などで名前を先行する。セッション値の設定には特別の権限は不要であるが、クライアントだけがそのセッション変数を変更できる。別のクライアントからはできない。

  • LOCAL および @@local.SESSION@@session. のシノニム。.

  • 修飾子がない場合は、SET でセッション変数を変更する。

SET ステートメントには複数の変数アサイメントがあり、カンマで区切ります。複数のシステム変数を設定する場合、ステートメント内で最新の GLOBAL または SESSION の修飾子を、後続の指定子のない変数に使用します。

例:

SET sort_buffer_size=10000;
SET @@local.sort_buffer_size=10000;
SET GLOBAL sort_buffer_size=1000000, SESSION sort_buffer_size=1000000;
SET @@sort_buffer_size=1000000;
SET @@global.sort_buffer_size=1000000, @@local.sort_buffer_size=1000000;

システム変数に値を SET で指定するときには、変数にスフィックス文字は使用しません。(起動オプションのときは使用する。) ただし、この値は例示のようにプログラミング形式にできます。

SET sort_buffer_size = 10 * 1024 * 1024;

システム変数の @@var_name シンタックスは、別のデータベース システムによっては互換性があります。.

セッション システム変数を変更する場合には、そのセッションが済むまで、または別の値に変更するまで、値の効力を維持します。この変更は別のクライアントには公開しません。

グローバル システム変数を変更すると、サーバが再起動するまで、値を新規接続で使用するものとして記憶します。(グローバル変数の設定を永続的にするには、オプション ファイルで設定する必要があります。) この変更は、そのグローバル変数にアクセスするすべてのクライアントに公開することになりますが、関連しているセッション変数への変更は、変更後に接続するクライアントに対してだけ反映します。グローバル変数の変更は、その時点で接続しているクライアントのセッション変数には反映しません。SET GLOBAL ステートメントを発行するクライアントからのイベントにも反映しません。

SET SESSION とだけ使用できる変数と SET GLOBAL を使用する場合、または GLOBAL (@@global.) をグローバル変数設定時に指定しない場合には、MySQL がエラー メッセージを出し、不正使用を防ぐことができます。

SESSION 変数を GLOBAL 値に、または GLOBAL 値をコンパイルされた MySQL のデフォルト値に設定するには、DEFAULT キーワードを使用します。たとえば、次の二つのステートメントは max_join_size のセッション値をグローバル値に設定するということにおいて、アイデンティカル (同一) です。

SET max_join_size=DEFAULT;
SET @@session.max_join_size=@@global.max_join_size;

すべてのシステム変数において、DEFAULT と設定することはできません。そのような場合には、DEFAULT の使用が、エラーの原因になります。

@@‐ 修飾子のひとつを使用して、プログラミングにおける特定のグローバルまたはセッションのシステム変数値を照会できます。たとえば、SELECT ステートメントの値を次のように読み出すことができます。

SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;

プログラミングでのシステム変数を @@var_name とすると、つまり, @@global. または @@session. を指定しないとき、MySQL はセッション値があれば、それを返しますが、ない場合はグローバル値を返します。これは常にセッション値とする SET @@var_name = value とは異なります。

ノート:システム変数によっては、SET ステートメントで値を ON または 1 に設定すると有効化し、OFF または 0 にすると無効化します。ただし、このような値をコマンドラインまたはオプション ファイルで設定するには、1 または 0 で設定します。ON または OFF での設定はできません。たとえば、コマンドラインにおいて、--delay_key_write=1 は機能しますが、--delay_key_write=ON では機能しません。

システム変数名と値を表示するには、 SHOW VARIABLES ステートメントを使用します。

mysql> SHOW VARIABLES;
+---------------------------------+-----------------------------------+
| Variable_name                   | Value                             |
+---------------------------------+-----------------------------------+
| auto_increment_increment        | 1                                 |
| auto_increment_offset           | 1                                 |
| automatic_sp_privileges         | ON                                |
| back_log                        | 50                                |
| basedir                         | /home/mysql/                      |
| binlog_cache_size               | 32768                             |
| bulk_insert_buffer_size         | 8388608                           |
| character_set_client            | latin1                            |
| character_set_connection        | latin1                            |
| character_set_database          | latin1                            |
| character_set_results           | latin1                            |
| character_set_server            | latin1                            |
| character_set_system            | utf8                              |
| character_sets_dir              | /home/mysql/share/mysql/charsets/ |
| collation_connection            | latin1_swedish_ci                 |
| collation_database              | latin1_swedish_ci                 |
| collation_server                | latin1_swedish_ci                 |
...
| innodb_additional_mem_pool_size | 1048576                           |
| innodb_autoextend_increment     | 8                                 |
| innodb_buffer_pool_awe_mem_mb   | 0                                 |
| innodb_buffer_pool_size         | 8388608                           |
| innodb_checksums                | ON                                |
| innodb_commit_concurrency       | 0                                 |
| innodb_concurrency_tickets      | 500                               |
| innodb_data_file_path           | ibdata1:10M:autoextend            |
| innodb_data_home_dir            |                                   |
...
| version                         | 5.1.6-alpha-log                   |
| version_comment                 | Source distribution               |
| version_compile_machine         | i686                              |
| version_compile_os              | suse-linux                        |
| wait_timeout                    | 28800                             |
+---------------------------------+-----------------------------------+

LIKE 節では、パターンに一致する変数だけを表示します。特定の変数名を得るには、LIKE 節を次のように使用します。

SHOW VARIABLES LIKE 'max_join_size';
SHOW SESSION VARIABLES LIKE 'max_join_size';

パターンに一致する名前を持つ変数のリストを得るには、LIKE 節で、‘%’ のワイルドカード文字を使用します。

SHOW VARIABLES LIKE '%size%';
SHOW GLOBAL VARIABLES LIKE '%size%';

ワイルドカード文字は、一致させるパターン内に入れます。厳密には、‘_’ シングル文字と一致するワイルドカードであるため、‘\_’ でエスケープして、文字通りに一致させます。実際には、これほどの厳密さは要求することはあまりありません。

SHOW VARIABLES では、GLOBAL または SESSION のいずれも指定しない場合、MySQL は SESSION 値を返します。

GLOBAL オンリーの変数を読み取るときではなく、設定するときに GLOBAL キーワードを必要とする理由は、今後の問題を防ぐためです。GLOBAL 変数と同じ名前を持つ SESSION 変数を取り除いた場合、SUPER 権限を持つクライアントが、接続時に SESSION 変数だけでなく、偶発的に GLOBAL 変数も変更してしまう可能性があります。SESSION 変数を GLOBAL と同じ名前で追加する場合、GLOBAL 変数を意図的に変更するクライアントで、クライアント自体の SESSION 変数だけが変更したと見なす可能性があります。

4.2.4.1. 構造化システム変数

構造化変数 (structured variable) は通常のシステム変数とは次の 2 点において異なります。

  • 値は、コンポーネントを伴うストラクチャであり、このコンポーネントとは、密接に関係している サーバ パラメータを指定するものである。

  • 構造化変数が特殊な場合には複数のインスタンスを伴うことがある。それぞれは異なる名前を持ち、サーバで維持しているリソースが異なる。

MySQL 5.1 でサポートする構造化変数は 1 つです。これでキー変更操作のパラメータを指定します。キー キャッシュの構造化変数には次のコンポーネントがあります。

  • key_buffer_size

  • key_cache_block_size

  • key_cache_division_limit

  • key_cache_age_threshold

このセクションでは、構造化変数に関するシンタックスについて説明します。キー キャッシュ変数はシンタックス例で使用しますが、キー キャッシュがどのように操作を行うかに関しては 項6.4.6. 「MyISAMキーキャッシュ」 を参照してください。

構造化変数のインスタンスのコンポーネントを示すには、instance_name.component_name 形式でコンパウンド名を使用します。次は、この例示です。

hot_cache.key_buffer_size
hot_cache.key_cache_block_size
cold_cache.key_cache_block_size

それぞれの構造化システム変数には、default 名のインスタンスを常に事前定義します。インスタンス名なしで構造化変数のコンポーネントを示すと、default インスタンスを使用することになります。つまり、default.key_buffer_sizekey_buffer_size の両方が同じシステム変数を指します。

構造化変数インスタンスとコンポーネントには次のネーミング ルールがあります。

  • 任意型の構造化変数には、それぞれのインスタンスに、そのタイプの変数内で 一意の名前を持たせる。ただし、インスタンス名は構造化変数型 全体 で一意である必要はない。たとえば、それぞれの構造化変数に default と名付けたインスタンスがある場合、default は変数型全体では一意ではない。

  • それぞれの構造化変数型のコンポーネントの名前は、システム変数名全体を通じて一意である必要がある。そうならない場合、つまり、型の異なる 2 つの構造化変数でコンポーネント メンバ名を共有している場合、インスタンス名で修飾していないメンバ名を参照するときに、どの構造化変数を使用するかを判断できなくなる。

  • 単純識別子 (unquoted identifier) としてはリーガルではない 構造化変数インスタンス名が、逆引用符を使用して単純識別子 (quoted identifier) になる (リーガルになる)。たとえば、hot-cache はリーガルでないが、`hot-cache` はリーガルである。

  • globalsessionlocal はリーガルのインスタンス名ではない。これは、非構造化システム変数を示すときに @@global.var_name などのノーテーションとの干渉を防ぐ。

現時点では、現在では、唯一の構造化変数の型がキー キャッシュのものであるため、最初の 2 ルールが違反対象になる可能性はありません。別の構造化変数の型を今後構築できれば、これらのルールはより大きな重要性を持つことになります。

例外として、単純変数名が発生するコンテキストに、コンパウンド名を使用する構造化変数コンポーネントを引き合わせることができます。たとえば、コマンドライン オプションで構造化変数に値を指定することができます。

shell> mysqld --hot_cache.key_buffer_size=64K

オプション ファイルで、次のシンタックスを使用します。

[mysqld]
hot_cache.key_buffer_size=64K

サーバをこのオプションで起動する場合、デフォルトの 8 MB のキー キャッシュに加えた、64 KB サイズの hot_cache と名づけられたキー キャッシュを生成することなります。

次のようにサーバを起動すると仮定した場合

shell> mysqld --key_buffer_size=256K \
         --extra_cache.key_buffer_size=128K \
         --extra_cache.key_cache_block_size=2048

この場合、サーバがデフォルト キー キャッシュを 256 KB に設定します。(--default.key_buffer_size=256K と記述することも可能。) さらに、このサーバは、extra_cache と名づけた 128KB のセカンド キー キャッシュとともに、2048 キロバイトのブロック バッファをテーブル インデックス ブロックのキャッシュ用に作成します。

次は、サイズが 3:1:1 の割合の 3 つのキー キャッシュでサーバを起動するときの例です。

shell> mysqld --key_buffer_size=6M \
         --hot_cache.key_buffer_size=2M \
         --cold_cache.key_buffer_size=2M

構造化変数値は、ランタイムでの設定、読み取りも可能です。たとえば、hot_cache という名前のキー キャッシュを 10 MB で設定するには、次のステートメントのどちらかを使用します。

mysql> SET GLOBAL hot_cache.key_buffer_size = 10*1024*1024;
mysql> SET @@global.hot_cache.key_buffer_size = 10*1024*1024;

キャッシュ サイズを読み取るには、次のことをします。

mysql> SELECT @@global.hot_cache.key_buffer_size;

ただし、次のようなステートメントは作用しません。この変数はコンパウンド名としての解釈にならず、LIKE 節のパターン一致操作の単純文字列としての解釈になります。

mysql> SHOW GLOBAL VARIABLES LIKE 'hot_cache.key_buffer_size';

これは、構造化変数名を単純変数名が発生する可能性があるところで使用できるようにしておくためです。

4.2.4.2. 動的システム変数

サーバのシステム変数の多くは動的で、SET GLOBAL または SET SESSION を使用してランタイムで設定できます。SELECT を使用して、値を取得することも可能です。項4.2.4. 「システム変数の使用」 を参照してください。

次のテーブルは、すべての動的システム変数の完全リストです。一番右のカラムはそれぞれの変数が、GLOBAL または SESSION、あるいは両方、のどれで適用するかを示します。テーブルには、SET ステートメントで設定できるセッション オプションをリストしています。項12.5.3. 「SET 構文」 では、これらのオプションについて説明しています。

string」 型の変数は文字列値で、「numeric」 型の変数は数値です。「boolean」 型の変数には 0、1、ONOFF で設定します。(コマンドラインまたはオプション ファイルでこれらを指定するときは、数値を使用します。) 「enumeration 」 (列挙) としてマークしている変数は通常、その変数に対して利用可能な値の 1 つで設定しますが、目的とする値に相当する数字でも設定できます。列挙型では、最初の値は 0 に相当します。これは、最初の列挙値が 1 に相当する ENUM カラムとは異なります。

変数名値のデータ型タイプ
autocommitbooleanSESSION
automatic_sp_privilegesbooleanGLOBAL
big_tablesbooleanSESSION
binlog_cache_sizenumericGLOBAL
binlog_formatstringGLOBAL | SESSION
bulk_insert_buffer_sizenumericGLOBAL | SESSION
character_set_clientstringGLOBAL | SESSION
character_set_connectionstringGLOBAL | SESSION
character_set_filesystemstringGLOBAL | SESSION
character_set_resultsstringGLOBAL | SESSION
character_set_serverstringGLOBAL | SESSION
collation_connectionstringGLOBAL | SESSION
collation_serverstringGLOBAL | SESSION
completion_typenumericGLOBAL | SESSION
concurrent_insertnumericGLOBAL
connect_timeoutnumericGLOBAL
default_week_formatnumericGLOBAL | SESSION
delay_key_writeOFF | ON | ALLGLOBAL
delayed_insert_limitnumericGLOBAL
delayed_insert_timeoutnumericGLOBAL
delayed_queue_sizenumericGLOBAL
div_precision_incrementnumericGLOBAL | SESSION
engine_condition_pushdownbooleanGLOBAL | SESSION
error_countnumericSESSION
event_schedulerenumerationGLOBAL
expire_logs_daysnumericGLOBAL
flushbooleanGLOBAL
flush_timenumericGLOBAL
foreign_key_checksbooleanSESSION
ft_boolean_syntaxstringGLOBAL
general_logbooleanGLOBAL
general_log_filestringGLOBAL
group_concat_max_lennumericGLOBAL | SESSION
identitynumericSESSION
innodb_autoextend_incrementnumericGLOBAL
innodb_commit_concurrencynumericGLOBAL
innodb_concurrency_ticketsnumericGLOBAL
innodb_max_dirty_pages_pctnumericGLOBAL
innodb_max_purge_lagnumericGLOBAL
innodb_support_xabooleanGLOBAL | SESSION
innodb_sync_spin_loopsnumericGLOBAL
innodb_table_locksbooleanGLOBAL | SESSION
innodb_thread_concurrencynumericGLOBAL
innodb_thread_sleep_delaynumericGLOBAL
insert_idnumericSESSION
interactive_timeoutnumericGLOBAL | SESSION
join_buffer_sizenumericGLOBAL | SESSION
key_buffer_sizenumericGLOBAL
last_insert_idnumericSESSION
lc_time_namesstringGLOBAL | SESSION
local_infilebooleanGLOBAL
log_outputstringGLOBAL
log_queries_not_using_indexesbooleanGLOBAL
log_warningsnumericGLOBAL
long_query_timenumericGLOBAL | SESSION
low_priority_updatesbooleanGLOBAL | SESSION
max_allowed_packetnumericGLOBAL | SESSION
max_binlog_cache_sizenumericGLOBAL
max_binlog_sizenumericGLOBAL
max_connect_errorsnumericGLOBAL
max_connectionsnumericGLOBAL
max_delayed_threadsnumericGLOBAL
max_error_countnumericGLOBAL | SESSION
max_heap_table_sizenumericGLOBAL | SESSION
max_insert_delayed_threadsnumericGLOBAL
max_join_sizenumericGLOBAL | SESSION
max_prepared_stmt_countnumericGLOBAL
max_relay_log_sizenumericGLOBAL
max_seeks_for_keynumericGLOBAL | SESSION
max_sort_lengthnumericGLOBAL | SESSION
max_tmp_tablesnumericGLOBAL | SESSION
max_user_connectionsnumericGLOBAL
max_write_lock_countnumericGLOBAL
multi_range_countnumericGLOBAL | SESSION
myisam_data_pointer_sizenumericGLOBAL
log_bin_trust_function_creatorsbooleanGLOBAL
myisam_max_sort_file_sizenumericGLOBAL | SESSION
myisam_repair_threadsnumericGLOBAL | SESSION
myisam_sort_buffer_sizenumericGLOBAL | SESSION
myisam_stats_methodenumGLOBAL | SESSION
myisam_use_mmapbooleanGLOBAL
ndb_extra_loggingnumericGLOBAL
net_buffer_lengthnumericGLOBAL | SESSION
net_read_timeoutnumericGLOBAL | SESSION
net_retry_countnumericGLOBAL | SESSION
net_write_timeoutnumericGLOBAL | SESSION
old_passwordsnumericGLOBAL | SESSION
optimizer_prune_levelnumericGLOBAL | SESSION
optimizer_search_depthnumericGLOBAL | SESSION
preload_buffer_sizenumericGLOBAL | SESSION
query_alloc_block_sizenumericGLOBAL | SESSION
query_cache_limitnumericGLOBAL
query_cache_sizenumericGLOBAL
query_cache_typeenumerationGLOBAL | SESSION
query_cache_wlock_invalidatebooleanGLOBAL | SESSION
query_prealloc_sizenumericGLOBAL | SESSION
range_alloc_block_sizenumericGLOBAL | SESSION
read_buffer_sizenumericGLOBAL | SESSION
read_onlynumericGLOBAL
read_rnd_buffer_sizenumericGLOBAL | SESSION
rpl_recovery_ranknumericGLOBAL
safe_show_databasebooleanGLOBAL
secure_authbooleanGLOBAL
server_idnumericGLOBAL
slave_compressed_protocolbooleanGLOBAL
slave_net_timeoutnumericGLOBAL
slave_transaction_retriesnumericGLOBAL
slow_query_logbooleanGLOBAL
slow_query_log_filestringGLOBAL
slow_launch_timenumericGLOBAL
sort_buffer_sizenumericGLOBAL | SESSION
sql_auto_is_nullbooleanSESSION
sql_big_selectsbooleanSESSION
sql_big_tablesbooleanSESSION
sql_buffer_resultbooleanSESSION
sql_log_binbooleanSESSION
sql_log_offbooleanSESSION
sql_log_updatebooleanSESSION
sql_low_priority_updatesbooleanGLOBAL | SESSION
sql_max_join_sizenumericGLOBAL | SESSION
sql_modeenumerationGLOBAL | SESSION
sql_notesbooleanSESSION
sql_quote_show_createbooleanSESSION
sql_safe_updatesbooleanSESSION
sql_select_limitnumericSESSION
sql_slave_skip_counternumericGLOBAL
updatable_views_with_limitenumerationGLOBAL | SESSION
sql_warningsbooleanSESSION
sync_binlognumericGLOBAL
sync_frmbooleanGLOBAL
storage_engineenumerationGLOBAL | SESSION
table_definition_cachenumericGLOBAL
table_open_cachenumericGLOBAL
table_typeenumerationGLOBAL | SESSION
thread_cache_sizenumericGLOBAL
time_zonestringGLOBAL | SESSION
timestampbooleanSESSION
tmp_table_sizeenumerationGLOBAL | SESSION
transaction_alloc_block_sizenumericGLOBAL | SESSION
transaction_prealloc_sizenumericGLOBAL | SESSION
tx_isolationenumerationGLOBAL | SESSION
unique_checksbooleanSESSION
wait_timeoutnumericGLOBAL | SESSION
warning_countnumericSESSION

MySQL Enterprise システム変数のコンフィギュレーションが不適切な場合、パフォーマンスとセキュリティに悪影響をもたらします。MySQL Network Monitoring and Advisory Service では、継続的にシステム変数の監視を行い、適切な設定を行うための専門アドバイスを提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

4.2.5. ステータス変数

サーバには様々なステータス変数が存在し、オペレーションに関する情報交換をしています。その変数と値は、SHOW [GLOBAL] STATUS ステートメントを使用して、閲覧できます。オプションの GLOBAL キーワードは全体的な接続において、値を集約します。

mysql> SHOW GLOBAL STATUS;
+-----------------------------------+------------+
| Variable_name                     | Value      |
+-----------------------------------+------------+
| Aborted_clients                   | 0          |
| Aborted_connects                  | 0          |
| Bytes_received                    | 155372598  |
| Bytes_sent                        | 1176560426 |
...
| Connections                       | 30023      |
| Created_tmp_disk_tables           | 0          |
| Created_tmp_files                 | 3          |
| Created_tmp_tables                | 2          |
...
| Threads_created                   | 217        |
| Threads_running                   | 88         |
| Uptime                            | 1389872    |
+-----------------------------------+------------+

ステータス変数の多くは、FLUSH STATUS ステートメントで 0 にリセットされる。

次に様々なステータス変数を示します。バージョンについて記載のない変数は MySQL 5.1 より前から 実装しています。実装履歴については、MySQL 5.0 Reference Manual を参照してください。

  • Aborted_clients

    接続を適切に閉じないままクライアントが終了したことが原因で中断した接続の数。項B.1.2.10. 「Communication Errors and Aborted Connections」 を参照のこと。

  • Aborted_connects

    MySQLサーバに接続しようとして失敗した回数。 項B.1.2.10. 「Communication Errors and Aborted Connections」 を参照のこと。

  • Binlog_cache_disk_use

    binlog_cache_sizeの値を超えてテンポラリ ログ キャッシュを使用したトランザクションの回数。トランザクションからステートメントを保存するためにテンポラリ ファイルを使用した場合。

  • Binlog_cache_use

    テンポラリ バイナリ ログ キャッシュを使用したトランザクションの回数。

  • Bytes_received

    すべてのクライアントから受信したバイト数。

  • Bytes_sent

    すべてのクライアントへ送信したバイト数。

  • Com_xxx

    Com_xxx ステートメントのカウンタ値は、それぞれの xxx ステートメントを実行した回数を示す。それぞれのステートメント タイプをそれぞれカウントする。たとえば、 DELETECom_delete を 1 とし、INSERTCom_insert を 1 としてカウントする。クエリ結果がクエリ キャッシュから返される場合は、サーバは Qcache_hits ステータス値の増加になる。Com_select ではないことに注意が必要。項4.13.4. 「クエリ キャッシュのステータスと保守」 を参照のこと。

    Com_stmt_xxx 値のすべては、準備された文 (prepared statement) の引数が未知、または実行中にエラーが発生した場合でも増加する。つまり、この値は、要求発行回数に対応し、要求を完了 (成功) した回数ではない。

    Com_stmt_xxx ステータス変数は次の通り。

    • Com_stmt_prepare

    • Com_stmt_execute

    • Com_stmt_fetch

    • Com_stmt_send_long_data

    • Com_stmt_reset

    • Com_stmt_close

    これらの変数は、準備された文 (prepared statement)。名前は ネットワーク レイヤーでし使用した COM_xxx

  • のコマンド セットを示す。つまり、mysql_stmt_prepare()mysql_stmt_execute() など、準備されたステートメントの API コールを実行すると、これらの値は増加する。PREPAREEXECUTEDEALLOCATE PREPARECom_stmt_prepareCom_stmt_executeCom_stmt_close に対応しているので、同様に増加する。さらに、MySQL 4.1.3 から実装しているため、古いステートメントのカウンタ値は、PREPAREEXECUTEDEALLOCATE PREPARECom_prepare_sqlCom_execute_sqlCom_dealloc_sql に対応しているので、これも同様に増加する。Com_stmt_fetch はカーソルからフェッチしたときにネットワーク往復を発行した合計回数のこと。

  • Compression

    接続でクライアント/サーバ間の圧縮プロトコルを 使用しているかどうか (を指す)。(MySQL 5.1.2での追加)

  • Connections

    (成功/不成功に関わらず) MySQL サーバへの接続試行回数。

  • Created_tmp_disk_tables

    ステートメント実行中に、ディスク上に作成された暗黙的テンポラリテーブルの数。

  • Created_tmp_files

    mysqld が生成したテンポラリ ファイルの数

  • Created_tmp_tables

    ステートメント実行中に、メモリ上に作成された暗黙的テンポラリテーブルの数。Created_tmp_disk_tables の値が大きい場合には、tmp_table_size の値も大きくすることによって、テンポラリテーブルをディスクベースではなくメモリベースにすることもできる。

  • Delayed_errors

    エラー発生(duplicate key の可能性)により、INSERT DELAYED で書き込まれたレコードの数。

  • Delayed_insert_threads

    INSERT DELAYED ハンドラ スレッドの数。

  • Delayed_writes

    INSERT DELAYED で書き込んだレコードの数。

  • Flush_commands

    FLUSH コマンドの実行回数。

  • Handler_commit

    内部 COMMIT コマンド数。

  • Handler_delete

    テーブルからレコードを削除した回数。

  • Handler_discover

    MySQL サーバが NDB Cluster ストレージエンジンに 指定の名前を持ったテーブル認識しているかどうかを問い合わせることができる。この操作をディスカバリー (discovery) と呼ぶ。 Handler_discover 値は、ディスカバーした回数。

  • Handler_prepare

    2 フェーズ コミット操作の準備フェーズのカウンタ。

  • Handler_read_first

    インデックスから最初のエントリを読み取った回数。 この値が大きい場合、サーバが何回もフル インデックス スキャンを実行している可能性がある。たとえば、SELECT col1 FROM foo を実行したときに、col1 がインデックスになっている場合など。

  • Handler_read_key

    キーに基づいたレコード読み込み要求を受けた回数。この値が大きい場合、クエリをテーブルへ適切にインデックス化していることを示す。

  • Handler_read_next

    キー順序で次レコードの読み込み要求を受けた回数。範囲指定をしてインデックス カラムに対してクエリを実行すると、これがインクリメントする。インデックス スキャンを実行した場合もインクリメントする。

  • Handler_read_prev

    キー順序で前レコードの読み込み要求を受けた回数。この読み取り方法は主に、ORDER BY ... DESC の最適化に使用している。

  • Handler_read_rnd

    固定位置に基づいたレコード読み込み要求を受けた回数。結果のソートを必要とするクエリを多く実行すると、この値が大きくなる。MySQL でテーブルの全件スキャンや適切にキーを使えない結合を持ったクエリがある可能性がある。

  • Handler_read_rnd_next

    データ ファイルで次レコードの読み取り要求を受けた回数。テーブル スキャンの実行が多いと、この値が大きくなる。これは通常、テーブルに適切なインデックス化できない、またはインデックスを利用できないクエリを発行していることを意味する。

  • Handler_rollback

    ROLLBACKを内部的 (ストレージ エンジン) に実行した回数。

  • Handler_savepoint

    内部的 (ストレージ エンジン) に セーブポイント (savepoint) の配置要求回数。

  • Handler_savepoint_rollback

    内部的 (ストレージ エンジン) に セーブポイント (savepoint) へロールバック要求回数。

  • Handler_update

    テーブル内のレコードの更新要求回数。

  • Handler_write

    テーブルへのレコードの挿入要求回数。

  • Innodb_buffer_pool_pages_data

    データがあるページ数 (ダーティ または クリーン)。

  • Innodb_buffer_pool_pages_dirty

    ダーティ ページの数。

  • Innodb_buffer_pool_pages_flushed

    InnoDB がキャッシュするために使用するメモリ バッファの数。

  • Innodb_buffer_pool_pages_free

    空き容量

  • Innodb_buffer_pool_pages_latched

    InnoDB のメモリ バッファでラッチした数。データが読み込みまたは書き込みの対象になっていて、フラッシュまたは削除が何らかの理由でできない状態。

  • Innodb_buffer_pool_pages_misc

    レコード ロックまたはアダプティブなハッシュ インデックスなどにより、オーバーヘッドの割り当てになったビジー (busy) 状態のデータ。この値は Innodb_buffer_pool_pages_total ? Innodb_buffer_pool_pages_free ? Innodb_buffer_pool_pages_data で算出。

  • Innodb_buffer_pool_pages_total

    ページのメモリ バッファの合計サイズ。

  • Innodb_buffer_pool_read_ahead_rnd

    InnoDB が開始した 「random (ランダム)」 先読みの数。大型テーブルのクエリ スキャンをランダムに行うと発生する。

  • Innodb_buffer_pool_read_ahead_seq

    InnoDB が開始した順次的な先読み数。InnoDBが 順次的にフル テーブル スキャンを行うときに発生する。

  • Innodb_buffer_pool_read_requests

    InnoDB が行った論理読み込みの数

  • Innodb_buffer_pool_reads

    InnoDBがバッファ プールの内容を利用できず、シングル ページ読み込みを行わなければならなかった論理読み込みの回数

  • Innodb_buffer_pool_wait_free

    ' 通常、InnoDB バッファ プールへの書き込みはバックグラウンドで行うが、ページの読み込みまたは作成を行う必要があるのに対して、クリーン ページが得られない場合に、まずそのページがフラッシュするまで待つ必要がある。このカウンタは、その待機回数をカウントする。バッファ プールの値が適切に設定すると、この値は小さくなる。

  • Innodb_buffer_pool_write_requests

    InnoDB バッファープールへの書き込み数。

  • Innodb_data_fsyncs

    ここまでの fsync() 操作数。

  • Innodb_data_pending_fsyncs

    現在の fsync() 操作保留 (pending) の数。

  • Innodb_data_pending_reads

    現在の読み込み保留の数。

  • Innodb_data_pending_writes

    現在の書き込み保留の数。

  • Innodb_data_read

    ここまでのデータの読み込み量 (単位:バイト)。

  • Innodb_data_reads

    データ読み込みの合計数。

  • Innodb_data_writes

    データ書き込みの合計数。

  • Innodb_data_written

    ここまでのデータの書き込み量 (単位:バイト)。

  • Innodb_dblwr_writes, Innodb_dblwr_pages_written

    二重書き込みの実行回数と、二重書き込みが発生したページ数。項13.5.14.1. 「InnoDB ディスク I/O」 を参照のこと。.

  • Innodb_log_waits

    ログ バッファが小さすぎるために、作業を継続する前にフラッシュ要求で待機した回数。

  • Innodb_log_write_requests

    要求ログ書き込みの回数。

  • Innodb_log_writes

    ログ ファイルへの物理的な書込みの回数。

  • Innodb_os_log_fsyncs

    ログ ファイルの fsync() 書き込みをした回数。

  • Innodb_os_log_pending_fsyncs

    fsync() 待ちのログ ファイル数。

  • Innodb_os_log_pending_writes

    ログ ファイルの書き込みの保留回数。

  • Innodb_os_log_written

    ログ ファイルへの書き込みの回数。

  • Innodb_page_size

    コンパイル時の InnoDB ページ サイズ (デフォルト 16KB)。多くの値がページ カウントの対象になり、ページ サイズは、それらを容易なバイト変換を可能にする。

  • Innodb_pages_created

    作成したページの数。

  • Innodb_pages_read

    読み込みしたページの数。

  • Innodb_pages_written

    書き込みしたページの数。

  • Innodb_row_lock_current_waits

    現在待機している行ロック (row lock) の数。

  • Innodb_row_lock_time

    行ロック (row lock)、列の獲得に使用した合計時間 (単位: ミリ秒)。

  • Innodb_row_lock_time_avg

    行ロック (row lock)、列の獲得に使用した平均時間 (単位: ミリ秒)。

  • Innodb_row_lock_time_max

    行ロック (row lock)、列の獲得に使用した最長時間 (単位: ミリ秒)。

  • Innodb_row_lock_waits

    行ロックで待機する必要があった回数。

  • Innodb_rows_deleted

    InnoDB テーブルから削除したレコード数。

  • Innodb_rows_inserted

    InnoDB テーブルへの挿入レコード数。

  • Innodb_rows_read

    InnoDB テーブルからの読み込みレコード数。

  • Innodb_rows_updated

    InnoDB テーブルでの更新レコード数。

  • Key_blocks_not_flushed

    変更後に、まだディスクに未フラッシュのキー キャッシュのキー ブロックの数。

  • Key_blocks_unused

    キー キャッシュの未使用ブロックの数。どれだけ使用しているか決定するためにこの値を使用する。項4.2.3. 「システム変数」key_buffer_size に関する説明を参照のこと。

  • Key_blocks_used

    キー キャッシュのブロックの使用数。この値は、これまで同時使用したブロックの最大数を指す頂点。

  • Key_read_requests

    キャッシュからキー ブロックを読み込んだリクエスト数。

  • Key_reads

    ディスクからのキーブロックの物理的読み込み回数。Key_reads が大きい場合、key_buffer_size の値が小さい可能性がある。キャッシュ ミス率は Key_reads/Key_read_requestsと計算する。

  • Key_write_requests

    キャッシュへのキーブロックの書き込んだリクエスト数。

  • Key_writes

    ディスクへのキー ブロックの物理的な書き込み回数。

  • Last_query_cost

    クエリ オプティマイザが計算し、最後にコンパイルしたクエリの全コスト。同じクエリの異なるクエリ プランのコストを比較するときに使用する。デフォルト値 0 は、クエリがまだ未コンパイルであることを意味する。Last_query_cost にはセッション スコープがある。

  • Max_used_connections

    サーバが起動してから同時使用した接続の最大数。

  • Ndb_cluster_node_id

    サーバが MySQL Cluster ノードとして作用している場合、この値はそのクラスタのノード ID。

    サーバが MySQL Cluster の一部ではない場合、この値は 0 。

  • Ndb_config_from_host

    サーバが MySQL Cluster の一部である場合、この値は Cluster マネージメント サーバのホスト名または IP アドレスで、コンフィギュレーション データを取得する。

    サーバが MySQL Cluster の一部ではない場合、この値は空文字列 。

    MySQL 5.1.12 以前では、この変数は Ndb_connected_host と呼ばれていた。

  • Ndb_config_from_port

    サーバが MySQL Cluster の一部である場合、この値はポート番号で、ここから、コンフィギュレーション データを取得する Cluster マネージメント サーバに接続。

    サーバが MySQL Cluster の一部ではない場合、この値は 0 。

    MySQL 5.1.12 以前では、この変数は Ndb_connected_port と呼ばれていた。

  • Ndb_number_of_data_nodes

    サーバが MySQL Cluster の一部である場合、この値はクラスタのデータ ノードの数。

    サーバが MySQL Cluster の一部ではない場合、この値は 0 。

    MySQL 5.1.12 以前では、この変数は Ndb_number_of_storage_nodes と呼ばれていた。

  • Not_flushed_delayed_rows

    INSERT DELAY 行列への書き込み待ちの行数。

  • Open_files

    開いているファイルの数。

  • Open_streams

    開いているストリームの数。(主に、ログの記録で使用)

  • Open_tables

    開いているテーブルの数。

  • Opened_tables

    これまでに開いたテーブル数。Opened_tables の値が多い場合、table_open_cacheの値が小さい可能性がある。

  • Prepared_stmt_count

    準備されたステートメントの現在の数。max_prepared_stmt_count で最大値を与える。(MySQL 5.1.14 での追加)

  • Qcache_free_blocks

    クエリ キャッシュ内の空きメモリ ブロックの数

  • Qcache_free_memory

    クエリ キャッシュ内の空きメモリ ブロック量

  • Qcache_hits

    クエリ キャッシュ ヒットの数。

  • Qcache_inserts

    キャッシュに追加したクエリ数。

  • Qcache_lowmem_prunes

    メモリ不足を解消するために、クエリ キャッシュから削除されたクエリの数。

  • Qcache_not_cached

    キャッシュしないクエリの数。(キャッシュできないか、または query_cache_type でキャッシュしない設定)

  • Qcache_queries_in_cache

    クエリ キャッシュに登録したクエリ数。

  • Qcache_total_blocks

    クエリ キャッシュの合計ブロック数。

  • Questions

    サーバに送信したクエリ数。

  • Rpl_status

    フェイル セーフ (安全装備) レプリケーションのステータス。未実装。

  • Select_full_join

    インデックスを使用しない結合の数 (テーブル スキャン)。この値が 0 でない場合、テーブルのインデックスを調べること。

  • Select_full_range_join

    関連テーブルで範囲検索を使用した結合の数。

  • Select_range

    ファースト テーブルで範囲指定した部分を使用した結合の数。 通常は、この数値が大きくても、それほど致命的な問題にはならない。

  • Select_range_check

    キーなしの結合の数。これは、それぞれのレコードのあとにキー使用をチェックする。この値が 0 でない場合、テーブルのインデックスをチェックする必要がある。

  • Select_scan

    ファースト テーブルのフル スキャンを行った結合の数。

  • Slave_open_temp_tables

    スレーブの SQL スレッドで現在開いているテンポラリ テーブルの数。

  • Slave_running

    サーバがマスタに接続しているスレーブの場合は、この値は ON

  • Slave_retried_transactions

    起動時から、レプリケーション スレーブの SQL スレッドがトランザクションを再試行した回数のこと。

  • Slow_launch_threads

    slow_launch_time 秒よりも、作成時間を要したスレッドの数。

  • Slow_queries

    slow_launch_time 秒よりも、作成時間を要したクエリの数。項4.11.5. 「スロー クエリ ログ」 を参照のこと。

  • Sort_merge_passes

    ソート アルゴリズムで必要としたマージ パスの回数。この値が大きい場合は、sort_buffer_size の値を大きくすることを検討する。

  • Sort_range

    範囲指定のソートを行った回数。

  • Sort_rows

    ソートしたレコードの数。

  • Sort_scan

    テーブル スキャンでソートした回数。

  • Ssl_xxx

    SSL接続に使用する変数 (ステータス)。

  • Table_locks_immediate

    テーブル ロックを直ちに実行した回数。

  • Table_locks_waited

    テーブル ロックをすぐには実行できず、待機が必要だった回数。この値が大きい場合、パフォーマンス上の問題がある。まずクエリを最適化し、次にテーブルを分割するかレプリケーションを行う。

  • Tc_log_max_pages_used

    mysqld で使用するログのメモリ マップ実装では、それ自体が内部の XA トランザクションのリカバリに対してトランザクション コーディネータとして作用するとき、この値は、サーバが起動してからログに使用したページの最大数を示す。Tc_log_max_pages_usedTc_log_page_size の積が常に、ログ サイズよりも極端に小さい場合は、そのサイズは必要以上に大きいことを示し、減らすことを検討する。このサイズは、--log-tc-size オプションで指定できる。現在、この変数は未使用。これはバイナリ ログをベースとしたリカバリには不要で、メモリ マップのリカバリ ログ方法は、ストレージ エンジンが2 フェーズ コミットより大きなものを許容できる場合を除き、使用しない。InnoDB は唯一、対応できるエンジンである。

  • Tc_log_page_size

    XA リカバリ ログのメモリ マップ実装のページ サイズ。デフォルトには getpagesize() を使用して値を決める。現在、この変数は未使用で、その理由は、Tc_log_max_pages_used に記述したものと同じである。

  • Tc_log_page_waits

    リカバリ ログのメモリ マップ実装で、この値は、サーバがトランザクションにコミットできず、ログの空きを待機する必要があると、その度にインクリメント (増加) する。この値が大きい場合、--log-tc-size オプションでログ サイズの増加を検討する。バイナリ ログをベースとしたリカバリでは、この値は、バイナリ ログが 2 フェーズ コミット中のために閉じることができない場合に、その度にインクリメントする。これは、対象となるすべてのトランザクションが完了するまで待機となる。

  • Threads_cached

    スレッド キャッシュ内のスレッド数。

  • Threads_connected

    現在開いている接続の数。

  • Threads_created

    接続を処理で作成されたスレッドの数。Threads_created の値が大きい場合、thread_cache_size の値を大きくして キャッシュ サイズを増やす。キャッシュヒット率の計算は Threads_created/Connections とする。

  • Threads_running

    スリープ状態になっていないスレッドの数。

  • Uptime

    サーバ起動時からの経過秒数。

4.2.6. SQL モード

MySQL サーバは様々な MySQL モードで動作し、モードをクライアント毎に別々に設定できます。この機能により、各アプリケーションが それぞれの要件に応じてサーバのオペレーティングモードを指定することができるようになります。

MySQL での SQL モードに関する FAQ は、項A.3. 「MySQL 5.1 FAQ ? Server SQL Mode」 を参照してください。

モードとは、どの SQL シンタックスを MySQL がサポートし、どのようなデータ バリデーション チェックを実行するべきかを定義するものです。これにいより、異なる環境で MySQL を使用したり、MySQL を他のデータベース サーバと併用したりするのが容易になります。

デフォルトの SQL モードを指定するには、--sql-mode="modes" オプションで mysqld を立ち上げます。または、Unix では my.cnf に、Window では my.iniに、sql-mode="modes" を記述します。modes とは、カンマ (「,」) で区切られた各モードのリストです。デフォルトは空の状態で、モード設定がないことを意味します。明示したい場合は、modes の値は空にできます。それには、コマンドラインで --sql-mode="" オプションを使用するか、あるいは、Unix では、my.cnf の 、Windows では my.inisql-mode="" オプションを使用します。

実行中に SQLモードを変更することもできます。 それには、SET [GLOBAL|SESSION] sql_mode='modes' 文で sql_mode の値を指定します。 GLOBAL 値を指定するには、SUPER 権限が必要になり、また、それ以降に接続するすべてのクライアント操作に影響します。SESSION 値を設定するには、現在設定を行った クライアントだけに影響します。クライアントは自身の sql_mode セッション値をいつでも変更できます。

次のステートメントで、現行のsql_mode のグローバル値とセッション値を読み取ることができます。

SELECT @@global.sql_mode;
SELECT @@session.sql_mode;

次に、最も重要な sql_mode 値を示します。

  • ANSI

    このモードは、標準 SQL とより同調できるように、シンタックス (構文) と動作を変更する。

  • STRICT_TRANS_TABLES

    指定された値をトランザクション テーブルに挿入できない場合、クエリの実行を中断する。非トランザクション テーブルでは、値が 1 行ステートメントの場合、または複数行ステートメントの最初の行である場合に、クエリを中断する。詳細は、このセクションでの後述を参照のこと。

  • TRADITIONAL

    MySQL を 「従来型の」 SQL データベース システムにように動作させる。このモードの最もシンプルな特徴は、カラムに不正値を挿入するときに、「警告ではなく、エラー メッセージ」 を返すことである。注意:INSERT/UPDATE は、エラーを認識すると即座に中断する。そのため、非トランザクション式のストレージ エンジンを使用している場合は、使用しない (推奨)。エラー前に変更したデータがロール バックしないため、更新が 「部分的に」 完了してしまうことがある。

このマニュアルで、 「Strict Mode」 と示すときは、STRICT_TRANS_TABLESSTRICT_ALL_TABLES の少なくなくともどちらかが有効化しているモードである、という意味です。

次のリストはサポートしている全モードの説明です。

  • ALLOW_INVALID_DATES

    日付の完全チェックを行わずに、月 は 1 から 12 まで、日は 1 から 31 までであることだけをチェックする。これは、たとえば、Web アプリケーションなどで年月日をそれぞれのフィールドで取得し、(日付に関するバリデーションなしで) ユーザが指定した通りに保存する場合に便利である。このモードは DATEDATETIME のカラムに適用する。TIMESTAMP カラムは常に有効な日付を必要とするため、対象外である。

    サーバでは月日の値は正当である必要があり、単に 1 から 12 そして 1 to 31 の範囲であるだけではいけない。Strict Mode を無効化した場合、'2004-04-31' のような入力は無効とみなし、'0000-00-00' と修正される。そのときには、警告が出される。Strict Mode を有効にした場合、無効とみなす日はエラーとなる。'2004-04-31' を許すには、ALLOW_INVALID_DATES を有効にする。

  • ANSI_QUOTES

    引用文字 ‘`’ のように、‘"’ を識別子として扱う。文字列の引用文字ではない。このモードを有効にした場合には、‘`’ を識別子として使用できる。ANSI_QUOTES を有効にした場合には、識別子として解釈されるため、リテラル文字列の引用には二重引用符を使用できなくなる。

  • ERROR_FOR_DIVISION_BY_ZERO

    INSERT または UPDATE 中に、0で除算 (または MOD(X,0)) すると、Strict Mode でエラーを生成する (そうでなければ、警告)。このモードを有効にしない場合、MySQL は 0 除算 に対して、NULL を返す。INSERT IGNORE または UPDATE IGNORE では、MySQL が 0 除算に対して警告を生成するが、操作結果は NULL になる。

  • HIGH_NOT_PRECEDENCE

    NOT 演算子の優先順位は、NOT a BETWEEN b AND cNOT (a BETWEEN b AND c) として構文解析するようなプログラム式である。古い MySQL バージョンでは、(NOT a) BETWEEN b AND c として構文解析している。以前の優先順位動作は、SQL モードの HIGH_NOT_PRECEDENCE を使用すると可能になる。

    mysql> SET sql_mode = '';
    mysql> SELECT NOT 1 BETWEEN -5 AND 5;
            -> 0
    mysql> SET sql_mode = 'HIGH_NOT_PRECEDENCE';
    mysql> SELECT NOT 1 BETWEEN -5 AND 5;
            -> 1
    
  • IGNORE_SPACE

    関数名と ‘(’ 文字のスペースを許可する。これは、組込み関数名を予約語として扱うようにする。そのため、関数名と同一の識別子を引用符で囲む必要がある。詳細は 項8.2. 「識別子」 を参照のこと。たとえば、COUNT() という関数があった場合、count をテーブル名として使用すると、次のようなステートメントでエラーが発生する。

    mysql> CREATE TABLE count (i INT);
    ERROR 1064 (42000): You have an error in your SQL syntax
    

    テーブル名は次のようにする。

    mysql> CREATE TABLE `count` (i INT);
    Query OK, 0 rows affected (0.00 sec)
    

    IGNORE_SPACEモードは、ユーザ定義関数 (UDF) または格納された関数ではなく、組み込み関数に適用する。IGNORE_SPACEを有効化しているかどうかに関わらず、ユーザ定義関数または格納された関数の後ろにスペースを入れることは常に可能である。

    IGNORE_SPACE に関する詳細は、項8.2.4. 「構文解析と解像度のファンクション名」 を参照のこと。

  • NO_AUTO_CREATE_USER

    GRANT 文が自動的に新規ユーザを作成しないようにする。空でないパスワードも指定した場合を除く。

  • NO_AUTO_VALUE_ON_ZERO

    NO_AUTO_VALUE_ON_ZEROAUTO_INCREMENT カラム処理に影響する。通常。次のシーケンス番号をカラムに生成するときには、NULL または 0 を挿入する。NO_AUTO_VALUE_ON_ZERO0 の動作を抑制するため、NULL が次のシーケンス番号を生成する。

    このモードでは、0 をテーブルの AUTO_INCREMENT カラムに格納する。しかし、0 を保存するということは、推奨できる方法ではない。たとえば、mysqldump コマンドでテーブルにダンプして、リロードする場合に、MySQL は, 0 という値に遭遇すると、新たなシーケンスン番号を生成し、テーブルにダンプしたものとは異なる内容になるという結果を生む。ダンプ ファイルをリロードする前に NO_AUTO_VALUE_ON_ZERO を有効にすると、この問題を回避できる。現在、mysqldump は、自動的にその出力に、NO_AUTO_VALUE_ON_ZERO を有効にするステートメントを含むようになったので、これまでの問題を回避できる。

  • NO_BACKSLASH_ESCAPES

    文字列内のエスケープ文字としてのバックスラッシュ (‘\’) を無効にする。このモードを有効にすると、バックスラッシュが特殊文字でなく通常の文字として扱われる。

  • NO_DIR_IN_CREATE

    テーブル作成時に、INDEX DIRECTORYDATA DIRECTORY の命令をすべて無視する。このオプションはスレーブのレプリケーション サーバで役立つ。

  • NO_ENGINE_SUBSTITUTION

    デフォルトのストレージ エンジンの自動置換 (substitution) を防ぐ。これは、CREATE TABLE のようなステートメントが、無効化した、またはコンパイルしたストレージ エンジンを指定するときのこと。エラーで知らせる。

  • NO_FIELD_OPTIONS

    MySQL 独自のカラムオプションを SHOW CREATE TABLE の出力に印字しない。このモードは mysqldump コマンドのポータビリティモードで使用される。

  • NO_KEY_OPTIONS

    MySQL 独自のインデックスオプションを SHOW CREATE TABLE の出力に印字しない。このモードは mysqldump コマンドのポータビリティモードで使用される。

  • NO_TABLE_OPTIONS

    MySQL 特化のテーブル オプション (ENGINE など) を SHOW CREATE TABLE の出力に印字しない。ポータビリティ モードで mysqldump コマンドを使用する。

  • NO_UNSIGNED_SUBTRACTION

    整数引き算操作で、オペランド (演算数) の一つに符号がない場合には、結果を UNSIGNED としてマークしない。つまり、引き算の結果はモードに効力がある場合は常に符号があり、オペランドの一つに符号がない場合でも同様。. たとえば、テーブル t1 のカラム c2 のタイプと、テーブル t2c2 のタイプを比較すると、次のようになる。

    mysql> SET SQL_MODE='';
    mysql> CREATE TABLE test (c1 BIGINT UNSIGNED NOT NULL);
    mysql> CREATE TABLE t1 SELECT c1 - 1 AS c2 FROM test;
    mysql> DESCRIBE t1;
    +-------+---------------------+------+-----+---------+-------+
    | Field | Type                | Null | Key | Default | Extra |
    +-------+---------------------+------+-----+---------+-------+
    | c2    | bigint(21) unsigned |      |     | 0       |       |
    +-------+---------------------+------+-----+---------+-------+
    
    mysql> SET SQL_MODE='NO_UNSIGNED_SUBTRACTION';
    mysql> CREATE TABLE t2 SELECT c1 - 1 AS c2 FROM test;
    mysql> DESCRIBE t2;
    +-------+------------+------+-----+---------+-------+
    | Field | Type       | Null | Key | Default | Extra |
    +-------+------------+------+-----+---------+-------+
    | c2    | bigint(21) |      |     | 0       |       |
    +-------+------------+------+-----+---------+-------+
    

    ノート: これは BIGINT UNSIGNED はすべての文脈で完全には使用できないことを意味する。項11.8. 「キャスト関数と演算子」 を参照のこと。.

    mysql> SET SQL_MODE = '';
    mysql> SELECT CAST(0 AS UNSIGNED) - 1;
    +-------------------------+
    | CAST(0 AS UNSIGNED) - 1 |
    +-------------------------+
    |    18446744073709551615 |
    +-------------------------+
    
    mysql> SET SQL_MODE = 'NO_UNSIGNED_SUBTRACTION';
    mysql> SELECT CAST(0 AS UNSIGNED) - 1;
    +-------------------------+
    | CAST(0 AS UNSIGNED) - 1 |
    +-------------------------+
    |                      -1 |
    +-------------------------+
    
  • NO_ZERO_DATE

    Strict Mode では、'0000-00-00' は有効な日として扱わない。IGNORE オプションで 「ゼロ」 の日付を挿入する。Strict Mode ではない場合は、この日付は有効になるが、警告が出る。

  • NO_ZERO_IN_DATE

    Strict Mode では、月日に 0 があった場合は、許可されない。IGNORE オプションで併用した場合は、MySQL が '0000-00-00' と入れ替える。Strict Mode ではない場合は、日付は有効になるが、警告が出る。

  • ONLY_FULL_GROUP_BY

    SELECT リストのクエリを許可しない。このリストは GROUP BY 節で名付けていない未集約のカラムを指す。次のクエリは、addressGROUP BY 節で名付づけていないので、このモードを有効にした場合は無効になる。

    SELECT name, address, MAX(age) FROM t GROUP BY name;
    

    MySQL 5.1.11 以後、このモードは、GROUP BY 節で名付けていない HAVING. の未集約カラムへのリファレンスを制限する。

  • PIPES_AS_CONCAT

    || を連結演算子として扱う。 (CONCAT() と同様に。) OR のシノニムとしては扱わない。

  • REAL_AS_FLOAT

    REALFLOAT のシノニムとして扱う。デフォルトでは、MySQL が REALDOUBLE のシノニムとして扱う。

  • STRICT_ALL_TABLES

    すべてのステーレジ エンジンに対して、Strict Mode を有効にする。無効データは排除の対象になる。詳細は、次のパラグラフを参照のこと。

  • STRICT_TRANS_TABLES

    トランザクションのストレージ エンジンに対して、Strict Mode を有効にする。非トランザクションのストレージ エンジンに対しても可能な場合ある。詳細は次のパラグラフを参照のこと。

Strict Mode は、MySQL が無効または不明な入力値をどのように処理するかを制御します。何らかの理由で値は無効になることがあります。たとえば、カラムに対して違うデータの入力、範囲を超える入力などがあった場合です。値が不明であるということは、挿入する新規のレコードに、カラム値がない場合で、定義に、明示的な DEFAULT 節がないときです。

トランザクション テーブルでは、無効または不明な値がクエリにある場合はエラーになります。これは、STRICT_ALL_TABLES または STRICT_TRANS_TABLES のどちらかのモードが有効になっている場合に起こります。クエリは中断、そしてロールバックの対象になります。

最初の行で挿入または更新するときに、bad 値が発生する場合、非トランザクションのテーブルでは、どちらのモードでも同様に動作します。クエリ処理は中断し、テーブルはそのまま変更なしの状態になります。クエリを挿入または複数行を変更した場合に、bad 値が2行目以降に発生する場合は、結果はどの制限オプションを有効に設定しているかに依存します。

  • STRICT_ALL_TABLES では、MySQL はエラーを返し、残りの行を無視する。そのような場合は、最初の段階の行がまだ挿入中または更新中であり、部分的な更新を得ることになり、それが予期していたものとは異なる可能性がある。これを回避するには、単行ステートメントを使用すると、テーブルを変更することなく、中断できる。

  • STRICT_TRANS_TABLESでは、MySQL は無効値を、カラムに対して最も近い有効値に置換し、調整した値を挿入する。値が不明である場合は、MySQL は、カラムのデータ タイプに明示的なデフォルト値を挿入する。どちらの場合でも、MySQL はエラーではなく、警告を出し、クエリ処理を続行する。明示的なデフォルトに関しては、項10.1.4. 「データタイプデフォルト値」 を参照のこと。

Strict Mode では、'2004-04-31' を無効な日付として扱います。'2004-04-00' または 「ゼロ」 日など、0 が部分的に含まれた日付は無効ではない。これらも無効として扱うには、Strict Mode の他に、NO_ZERO_IN_DATENO_ZERO_DATE の SQL モードも追加する。.

Strict Mode を使用しない場合、つまり、STRICT_TRANS_TABLES または STRICT_ALL_TABLES のどちらかを有効にした場合、MySQL は無効または不明な値の代わりに調整した値を挿入し、警告を出す。Strict Mode では、INSERT IGNORE または UPDATE IGNORE を使用して、このような動作を導くことが可能。項12.5.4.31. 「SHOW WARNINGS 構文」 を参照のこと。

次に示すモードは特化型のモードで、前述したモード値のコンビネーションの省略表現でもあります。

説明にあるモード値は、最新の MySQL バージョンで利用できます。古いバージョンの場合は、コンビネーション モードで新しいバージョンでだけ使えるモードを使用しているため、利用できません。

  • ANSI

    REAL_AS_FLOATPIPES_AS_CONCATANSI_QUOTESIGNORE_SPACE に相当。 項1.8.3. 「ANSIモードでのMySQLの実行」 を参照のこと。

  • DB2

    PIPES_AS_CONCATANSI_QUOTESIGNORE_SPACENO_KEY_OPTIONSNO_TABLE_OPTIONSNO_FIELD_OPTIONS に相当。

  • MAXDB

    PIPES_AS_CONCATANSI_QUOTESIGNORE_SPACENO_KEY_OPTIONSNO_TABLE_OPTIONSNO_FIELD_OPTIONSNO_AUTO_CREATE_USER に相当。

  • MSSQL

    PIPES_AS_CONCATANSI_QUOTESIGNORE_SPACENO_KEY_OPTIONSNO_TABLE_OPTIONSNO_FIELD_OPTIONS に相当。

  • MYSQL323

    NO_FIELD_OPTIONSHIGH_NOT_PRECEDENCE に相当。

  • MYSQL40

    NO_FIELD_OPTIONSHIGH_NOT_PRECEDENCE に相当。

  • ORACLE

    PIPES_AS_CONCATANSI_QUOTESIGNORE_SPACENO_KEY_OPTIONSNO_TABLE_OPTIONSNO_FIELD_OPTIONSNO_AUTO_CREATE_USER に相当。

  • POSTGRESQL

    PIPES_AS_CONCATANSI_QUOTESIGNORE_SPACENO_KEY_OPTIONSNO_TABLE_OPTIONSNO_FIELD_OPTIONS に相当。

  • TRADITIONAL

    STRICT_TRANS_TABLESSTRICT_ALL_TABLESNO_ZERO_IN_DATENO_ZERO_DATEERROR_FOR_DIVISION_BY_ZERONO_AUTO_CREATE_USER に相当。

4.2.7. シャットダウン プロセス

サーバのシャットダウン プロセスには次のことが行われます。

  1. シャットダウン プロセスの開始

    サーバのシャットダウン (システム終了) には様々な方法があります。たとえば、SHUTDOWN 権限を持つユーザは、mysqladmin shutdown コマンドを実行できます。MySQL がサポートしているプラットフォームであれば mysqladmin コマンドを使用します。OS に対応したシャットダウンの開始方法として、Unix 環境のシャットダウンでは、サーバが SIGTERM を受けるとシャットダウンし、Windows 環境では、サービス マネージャの指示でシャットダウンします。

  2. サーバによるシャットダウン スレッドの作成 (必要に応じて)

    シャットダウンの開始方法によっては、サーバがシャットダウン プロセスを処理するスレッドを作成することがあります。シャットダウンがクライアントからの要求によるのであった場合に、シャットダウン スレッドが作成されます。シャットダウンが SIGTERM を受信したことによるものである場合、シャットダウン処理をグナル スレッド (SIGTERM に対して) が行うことがあります。または、別のスレッドを作成して、その処理を行うことがあります。サーバがシャットダウン スレッドを作成しようとして、作成できない場合には、サーバは診断メッセージをエラー ログに表示します。これは、メモリ不足などの場合に発生します。

    Error: Can't create thread to kill server
    
  3. サーバによる新規接続の拒否

    シャットダウン中に新たなアクティビティを開始しないようにするために、サーバは新たなクライアントからの接続を拒否します。これは、P ポート、Unix のソケット ファイル、Windows の名前付きパイプや共有ファイルなどの接続に対して、ネットワーク接続を閉じる、という方法を取ります。

  4. サーバによる現行のアクティビティの停止

    クライアント接続に関連しているスレッドでは、クライアントへの接続を止め、そのスレッドはバイタルを失った (無くなった) ものとしてマークします。スレッドはそのようにマークされたことを認識し、消滅します。アイドル接続のスレッドは、簡単に消滅します。クエリを処理中のスレッドはその程度を定期的に把握しているために、消滅するまでに時間がかかります。スレッド停止に関する詳細は、項12.5.5.3. 「KILL 構文」 を参照してください。このリンクでは、MyISAM テーブルでの REPAIR TABLE または OPTIMIZE TABLE オペ中の消滅に関して特記しています。

    オープン トランザクションのスレッドは、トランザクションがロールバックします。ノート: スレッドが非トランザクションのテーブルを更新中の場合には、UPDATE または INSERT などのオペレーションでテーブルを部分的に更新した状態にすることがあります。これはオペレーションが完了する前に停止する可能性があるためです。

    サーバがマスタのレプリケーション サーバである場合は、スレッドは接続中のサーバに関連するスレッドを別のクライアントからのスレッドのように扱います。そのため、レプリケーションに関係しているスレッドはバイタルを失い、状態のチェックが済むと終了します。

    サーバがすスレーブのレプリケーション サーバである場合、I/O と SQL のスレッドがアクティブなときには、クライアント スレッドが失われる前に中断します。SQL スレッドは現行クエリを完了してから、中断します。これにより、レプリケーションで問題が発生しないようにします。SQL スレッドがその時点でトランザクションの最中であった場合は、トランザクションがロールバックします。

  5. ストレージ エンジンのシャットダウンまたはクローズ

    この段階で、テーブル キャッシュはフラッシュが済み、オープン テーブルのすべてを閉じます。

    それぞれのストレージ エンジンでは、関係しているテーブルに対して必要なアクションを取ります。たとえば、MyISAM では、テーブルへのインデックスの書き込みで保留中のものをフラッシュします。InnoDB では、ディクスにバッファ メモリをフラッシュします。その時点での LSN をテーブルスペースへ書き込み、内部スレッドを停止します。innodb_fast_shutdown で 2 と設定していた場合はこの限りではありません。

  6. サーバの終了

4.2.8. サーバ サイド ヘルプ

MySQL サーバは HELP ステートメントをサポートしています。これは、MySQL リファレンス マニュアルからオンライン情報を表示します。(項12.3.2. 「HELP 構文」 を参照のこと。) 適切な操作を行うには、mysql データベースのヘルプ テーブルにヘルプのトピック情報が必要です。ここでは、fill_help_tables.sql スクリプトの内容を処理して行います。

Unix における MySQL の バイナリ 配布は、mysql_install_db を実行するとヘルプ テーブルのセットアップが出てきます。Linux の RPM 配布、または Windows のバイナリ配布は、ヘルプ テーブルのセットアップは MySQL をインストールする過程で行います。

MySQL のソース配布は、scripts ディレクトリで、fill_help_tables_sql ファイルを探してください。このファイルを手動でロードするときには、mysql_install_db コマンドを実行して、mysql データベースを初期化し、次のように mysql クライアントでファイルをプロセスします。

shell> mysql -u root mysql < fill_help_tables.sql

BitKeeper または MySQL の開発ソース ツリーで作業をしている場合、ツリーには fill_help_tables.sql ファイルが含まれていません。そのため、http://dev.mysql.com/doc/ から、使用している MySQL バージョンに必要なファイルをダウンロードしてください。ダウンロードが済んだら、そのファイルを解凍して、記述のように mysql でそのファイルを処理してください。

4.3. MySQL サーバ スタートアップ プログラム

このセクションでは、MySQL サーバ、つまり mysqld を立ち上げるために使用するプログラムについて説明します。.

4.3.1. mysqld_safe ? MySQL サーバ スタートアップ スクリプト

mysqld_safe は Unix や NetWare などの環境で、mysqld サーバ ( デーモン) を起動するときに推奨しているコマンドです。mysqld_safe は、エラー発生時にサーバを再起動したり、ランタイム情報をログ ファイルに記録するなどのセキュリティ機能が加わります。 NetWare に特化した動作に関しては、このセクションの後方で説明します。

mysqld_safe は、mysqld という名前の実行可能ファイルを立ち上げます。デフォルトの動作を書き換えて、特定のサーバを指定するには、mysqld_safe--mysqld または --mysqld-version のオプションを指定します。--ledir オプションで、mysqld_safe がサーバとして使用するディレクトリを指定できます。

mysqld_safe でのオプションは、mysqld のオプションと同じです。詳細は 項4.2.2. 「コマンド オプション」 を参照してください。.

コマンドラインから mysqld_safe に指定したオプションのすべては、mysqld に渡ります。mysqld_safe へ特定のオプションを使用し、それを mysqld がサポートしない場合は、コマンドラインでの指定はしないでください。その代わりに、オプション ファイルの [mysqld_safe] グループでそれらをリストしてください。詳細は、項3.3.2. 「オプションファイルの使用」 を参照してください。

mysqld_safe は、オプション ファイルの [mysqld][server][mysqld_safe] のセクションからすべてのオプションを読み取ります。下位互換の場合でも、 [safe_mysqld] セクションから読みますが、MySQL 5.1 をインストールするときに、該当するセクションを [mysqld_safe] へとリネームする必要があります。

mysqld_safe は次のオプションをサポートします。

  • --help

    ヘルプメッセージを表示し、終了。

  • --autoclose

    NetWare 専用。NetWare では、mysqld_safe がスクリーン表示を行う。mysqld_safe NLM をアンロード (シャットダウン) するときは、デフォルトでスクリーンが消えることはなく、代わりにユーザ入力をプロンプトする。

    *<NLM has terminated; Press any key to close the screen>*
    

    NetWare で、自動的にスクリーンを閉じるようにするには、mysqld_safe--autoclose オプションを使用する。

  • --basedir=path

    基準パス。MySQLをインストールしているディレクトリを指す。

  • --core-file-size=size

    mysqld で作成するコア ファイルのサイズ。このオプション値は ulimit -c へ渡る。

  • --datadir=path

    データ ディレクトリへのパス。

  • --defaults-extra-file=path

    通常のオプションファイルのほかに、読み込むオプション ファイルの名前。このオプションを使用するときは、これをコマンドラインで最初のオプションにする。このファイルが存在しない、またはアクセスできないという場合には、サーバがエラーを出して終了する。

  • --defaults-file=file_name

    通常のオプション ファイルの代わりに読み込むオプション ファイルの名前。このオプションを使用するときには、これをコマンドラインで最初のオプションにする。

  • --ledir=path

    mysqld_safe でサーバをみつけることができない場合、このオプションでサーバがあるディレクトリへのパス探す。.

  • --log-error=file_name

    任意のファイルにエラー ログを書き込む。項4.11.2. 「エラー ログ」 を参照のこと。

  • --mysqld=prog_name

    ledir ディレクトリにある (起動する) サーバ プログラムの名前。このオプションは、MySQL バイナリ配布を使用するが、バイナリ配布外にデータ ディレクトリがある場合に、このオプションを使用する。mysqld_safe でサーバをみつけることができない場合は、 --ledir オプションを使用して、サーバ ディレクトリのパスを探す。

  • --mysqld-version=suffix

    --mysqld オプションと類似のオプション。ここではサーバのプログラム名 (mysqld) のサフィックスだけを指定する。ベース名を mysqld とする。たとえば、--mysqld-version=debug を使用すると、mysqld_safeledir ディレクトリの mysqld-debug プログラムを起動する。--mysqld-version の引数が空白の場合、mysqld_safeでは、ledir ディレクトリの mysqld を使用する。

  • --nice=priority

    nice プログラムは任意の値に対してサーバのスケジュール優先順位を設定する。

  • --no-defaults

    オプション ファイルを読まない。このオプションを使用するときは、コマンドラインの最初に置く。

  • --open-files-limit=count

    mysqld が開くファイル数。オプション値は ulimit -n へ渡る。ノート:正確に機能させるには、mysqld_saferoot として立ち上げる。

  • --pid-file=file_name

    ID ファイルのパス名

  • --port=port_num

    TCP/IP 接続時に使用するポート番号。ポート番号は 1024 以上にする。サーバが root システム ユーザで立ち上がっている場合はこの限りではない。

  • --socket=path

    サーバがローカル接続に使用するUnix のソケット ファイル。

  • --timezone=timezone

    TZ タイム ゾーンの環境変数を任意のオプション値に設定する。正規 (リーガル) のタイム ゾーン形式に関しては、オペレーティング システムのマニュアルを参照のこと。

  • --user={user_name|user_id}

    mysqld サーバを、user_name (名前)、または user_id (数字のユーザ ID) を保有するユーザとして実行する。ここでの 「ユーザ」 は、権限テーブルにリストしている MySQL ユーザではなく、システム ログイン アカウントを指す)。

mysqld_safe を実行するときに、 --defaults-file または --defaults-extra-option のオプションをオプション ファイルとするときに、このオプションをコマンドラインの最初に置く。そうしないと、オプション ファイルは使用できません。たとえば、次のコマンドはオプション ファイルとして使用することはできません。

mysql> mysqld_safe --port=port_num --defaults-file=file_name

代わりに、次のコマンドを使用します。

mysql> mysqld_safe --defaults-file=file_name --port=port_num

mysqld_safe スクリプトを書くと、通常はソースまたは MyQL のバイナリ配布からインストールしたサーバを立ち上げることができ、これは、このようなタイプの配布を通常とは異なる場所にインストールする場合も同様です。(項2.1.5. 「インストールのレイアウト」 を参照のこと。) mysqld_safe では、次の条件が true である必要があります。

  • サーバとデータベースは作業中のディレクトリと関連する。つまり mysqld_safe から呼び出したディレクトリであること。バイナリ配布の場合、mysqld_safe は、bindata のディレクトリにあり、ソース配布の場合は、libexecvar のディレクトリにある。この条件が一致していると、MySQL をインストールしたディレクトリから mysqld_safe を実行できる。たとえば、バイナリ配布の場合には、/usr/local/mysql である。

  • サーバとデータベースが作業中のディレクトリと関連しない場合は、mysqld_safe は絶対パスで探そうとする。通常は、/usr/local/libexec/usr/local/var に位置する。実際の場所は、構築したとき設定した値で決定する。MySQL を設定時に指定の場所へインストールしていれば、正確に動作する。

mysqld_safe は作業中のディレクトリに関連しているサーバとデータベースを探すため、基本的には MySQL のバイナリ配布をどこにでもインストールできますが、mysqld_safe の実行は、MySQL をインストールしたディレクトリである必要があります。

shell> cd mysql_installation_directory
shell> bin/mysqld_safe &

MySQL をインストールしたディレクトリから呼び出しても、mysqld_safe で失敗する場合、--ledir または --datadir オプションで指定して、システム内のサーバとデータベースがあるディレクトリを指してください。

通常、mysqld_safe のスクリプトは編集してはいけません。その必要がある場合には、mysqld_safemy.cnf オプション ファイルの [mysqld_safe] セクションにあるコマンドライン オプションを使用します。稀なケースでは、サーバを正確に起動するために、mysqld_safe を編集する必要があります。これを行う場合、mysqld_safe を修正しても、MySQL をアップグレードするときに、上書きされてしまうため、その修正バージョンのコピーを再インストールように控えておくことをお勧めします。

NetWare では、mysqld_safe が NetWare Loadable Module (NLM) であり、オリジナルの Unix シェル スクリプトからポートしています。この場合には、サーバは次のような経緯で立ち上がります。

  1. 数々のシステムを実行し、オプション チェックを行う。

  2. MyISAM テーブルのチェックをする。

  3. MySQL サーバにスクリーンのプレゼンスを規定する。

  4. mysqld を立ち上げ、それを監視し、再起動するときに、エラーで終了するかどうかをみる。

  5. データ ディレクトリに mysqld から host_name.err へエラー メッセージを送る。

  6. mysqld_safe のスクリーン出力をデータ ディレクトリの host_name.safe ファイルへ送る。

4.3.2. mysql.server ? MySQL サーバ スタートアップ スクリプト

Unix の MySQL 配布には、mysql.server というスクリプトがあります。これは、System V-style が実行するディレクトリで使用するシステム、たとえば、Linux や Solaris などで、システム サービスを起動または停止するために使用します。 MySQL 用の Mac OS X Startup Item でも使用できます。

mysql.server コマンドは、MySQL をインストールしたディレクトリ、または MySQL のソース配布の support-files にあります。

Linux の RPM パッケージ (MySQL-server-VERSION.rpm) の場合は、mysql.server スクリプトを /etc/init.d のディレクトリに mysql という名前でインストールします。手動でインストールする必要はありません。Linux RPM パッケージに関する詳細は、項2.4. 「Linux に MySQL をインストールする」 を参照してください。

ベンダーによっては、mysqld などの異なる名前でスタートアップ スクリプトをインストールする RPM パッケージを提供しています。

自動的に mysql.server をインストールしないバイナリ配布形式、またはソース配布から MySQL をインストールする場合は、手動でインストールすることもできます。手順は 項2.10.2.2. 「MySQL を自動的に起動・停止する」 を参照してください。

mysql.server はオプション ファイルの [mysql.server][mysqld] のセクションからオプションを読みます。下位互換の場合には、[mysql_server] から読みますが、MySQL を使用するのであれば、[mysql.server] とセクションをリネームする必要があります。

4.3.3. mysqld_multi ? 複数のMySQL サーバ管理

mysqld_multi は複数の mysqld プロセス管理を目的とした、Unix ソケット ファイルや TCP/IP ポートからの接続を処理するプログラムです。これは、サーバを起動、停止、そしてステータスを報告します。MySQL Instance Manager は複数サーバのマッピッグの選択的な方法です。MySQL Instance Manager に関する詳細は、項4.4. 「mysqlmanager ? MySQL Instance Manager」 を参照してください。

mysqld_multi[mysqldN] と名付けれらたグループを my.cnf から検索します。(または --config-file オプションで指定しているファイル。) ここで、N は正の整数です。この番号は次の説明でのオプション グループ番号、あるいは GNR とします。グループ番号はオプション グループを識別、起動、停止、またはステータス レポートを取得するなど、サーバに指定する mysqld_multi の引数として使用します。(例は、項2.10.2.2. 「MySQL を自動的に起動・停止する」 を参照のこと。) 複数のサーバを使用する場合には、それぞれのサーバで、Unix ソケット ファイルや TCP/IP ポート番号への別々のオプションを使用する必要があります。複数サーバの環境で、どのオプションを一意とする必要があるのかについては、項4.12. 「同じマシン上での複数 MySQL サーバの実行」 を参照してください。

mysqld_multi を呼び出すには、次のシンタックスを使用します。

shell> mysqld_multi [options] {start|stop|report} [GNR[,GNR] ...]

startstopreport は、どのオペレーションを実行するかを指します。サーバが 1 つの場合、または複数の場合でも指定したオペレーションを実行できますが、これは、オプションに従う GNR リストによります。リストがない場合は、mysqld_multi がオプション ファイル内ですべてのサーバのオペレーションを実行します。

GNR はそれぞれに、オプション グループ番号、またはグループ番号の範囲を表します。値は、オプション ファイルのグループ名の末尾の数字になります。たとえば、 [mysqld17] というグループ名の GNR17 です。番号の範囲を指定するには、最初と最後の番号をダッシュで区切ります。たとえば、GNR 値 を 10-13 とするときは、[mysqld10] から [mysqld13] のグループを表します。複数のグループや範囲を指定するには、コマンドラインで、カンマ区切りをして指定します。GNR リストには空白文字 (スペース、タブなど) を使用しないでください。空白文字から後にあるものは無視の対象になります。

次のコマンドは [mysqld17] というオプション グループを使用したシングル サーバを起動します。

shell> mysqld_multi start 17

次のコマンドは、[mysqld8][mysqld10] から [mysqld13] までのオプション グループを使用しているサーバ (複数) を停止します。

shell> mysqld_multi stop 8,10-13

オプション ファイルの設定例には、次のコマンドを使用します。

shell> mysqld_multi --example

mysqld_multi では、次のオプションをサポートします。

  • --help

    ヘルプメッセージを表示し、終了。

  • --config-file=file_name

    代替オプション (設定) ファイル。これは、mysqld_multi[mysqldN] オプション グループを探すときに影響する。このオプションがない場合、すべてのオプションは通常の my.cnf ファイルから読み取る。このオプションは、mysqld_multi が独自のオプションを読むときには影響しない。つまり常に、[mysqld_multi] グループを通常の my.cnf ファイルから読み取る。

  • --example

    サンプルのオプション ファイルを表示する。

  • --log=file_name

    ログ ファイルを指定する。このファイルが存在していれば、すべてがログ ファイルへの記録になる。

  • --mysqladmin=prog_name

    サーバ停止 (シャットダウン) に使用する mysqladmin バイナリ。

  • --mysqld=prog_name

    使用する mysqld バイナリ。ノート: このオプションに mysqld_safe を値として指定することもできる。mysqld_safe をサーバの起動に使用する場合は、[mysqldN] オプション グループに相当する mysqld または ledir などのオプションを含めることができる。これらのオプションは、mysqld_safe が起動するサーバの名前とサーバが置かれているディレクトリのパスを指す。(これらのオプションに関する説明は、項4.3.1. 「mysqld_safe ? MySQL サーバ スタートアップ スクリプト」 を参照のこと。) 次は例示。

    [mysqld38]
    mysqld = mysqld-debug
    ledir  = /opt/local/mysql/libexec
    
  • --no-log

    ログ ファイルではなく、stdout にログを書き込む。デフォルトはログ ファイルへの出力。

  • --password=password

    mysqladmin を呼び出すときに使う MySQL アカウント ユーザのパスワード。ノート: MySQL プログラムの場合とは異なり、パスワード値はこのオプションではオプショナルではない。

  • --silent

    サイレント モード、警告を無効にする。

  • --tcp-ip

    MySQL サーバを TCP/IP ポートまたは Unix ソケット ファイルを経由して接続する。ソケット ファイルがない場合でも、サーバは実行可能であるが、TCP/IP ポートからだけアクセスできる。デフォルトでは、Unix ソケット ファイルを使用した接続。このオプションは stopreport の操作に影響する。

  • --user=user_name

    mysqladmin を呼び出すときの MySQL アカウントのユーザ名。

  • --verbose

    冗長にする。(出力をより詳細にする。)

  • --version

    バージョン情報を表示して、終了する。

次は、mysqld_multi に関するノートです。

  • 重要mysqld_multi コマンドを使用する前には、mysqld サーバへ渡すオプションの意味と、なぜmysqld プロセスを区切る必要があるのかを十分に理解してください。同じデータ ディレクトリで複数の mysqld サーバを使用することには危険が伴います。これを複数のサーバを使用するときは、データ ディレクトリを別々に分けてください。同じデータ ディレクトリで複数のサーバを使用することが、スレッド システム のパフォーマンス改善にはなりません項4.12. 「同じマシン上での複数 MySQL サーバの実行」 を参照してください。

  • 重要 :それぞれのサーバのデータ ディレクトリが Unix アカウントから完全にアクセスできるかどうかを確かめてください。このアカウントは特定の mysqld プロセスを起動するものです。これに、状況を完全に 理解していない場合は、Unix root アカウントを 使用しない でください。項4.6.5. 「ユーザによる MySQL の実行」 を参照してください。

  • mysqld サーバを (mysqladmin プログラムで) 終了するときに使用する MySQL アカウントが、それぞれのサーバで同一のユーザ名とパスワードであることを確かめてください。そのアカウントには SHUTDOWN 権限があることも確かめてください。管理するサーバで、管理アカウント用に異なるユーザ名とパスワードがにある場合は、それぞれのサーバで同一のユーザ名とパスワードのアカウントを作成してください。たとえば、共通の multi_admin アカウントをセットアップします。これには、次のコマンドをそれぞれのサーバで実行します。

    shell> mysql -u root -S /tmp/mysql.sock -p
    Enter password:
    mysql> GRANT SHUTDOWN ON *.*
        -> TO 'multi_admin'@'localhost' IDENTIFIED BY 'multipass';
    

    項4.7.2. 「権限システムの機能」 を参照してください。これは、それぞれの mysqld サーバで行ってください。それぞれにアクセスするときに、接続パラメータを適宜に変更します。ノート: アカウント名のホスト名の部分は、mysqld_multi を実行する所のホストから multi_admin として接続できるようにします。

  • Unix ソケット ファイルと TCP/IP ポート番号は、すべての mysqld とは異なる必要があります。

  • --pid-file オプションはとても重要です。たとえば、--mysqld=mysqld_safe などのように、mysqld を起動するときに mysqld_safe を使用している場合と特に重要です。どの mysqld コマンドにも独自のプロセス ID ファイルがあります。mysqld ではなく、mysqld_safe を使用するということには、mysqld_safemysqld のプロセスを監視しているため、kill -9 を使用したシグナル送信や、segmentation fault のようなことがあると、プロセスを終了し、再起動するという利点があります。mysqld_safe スクリプトは特定の場所から開始しなければならいことがあります。これは、mysqld_multi を実行する前に、特定のディレクトリに位置を変更しなけれならない可能性がある、ということです。起動時に問題がある場合は、 mysqld_safe スクリプトを調べ、特に次のラインをチェックください。

    ----------------------------------------------------------------
    MY_PWD=`pwd`
    # Check if we are starting this relative (for the binary release)
    if test -d $MY_PWD/data/mysql -a \
       -f ./share/mysql/english/errmsg.sys -a \
       -x ./bin/mysqld
    ----------------------------------------------------------------
    

    これらのラインでテストすると成功しますが、そうでない場合、つまり問題がある場合は、項4.3.1. 「mysqld_safe ? MySQL サーバ スタートアップ スクリプト」 を参照してください。

  • --user オプションを mysqld に使用する場合は、 Unix root ユーザで mysqld_multi スクリプトを実行する必要があります。このオプションがオプション ファイルにあるかどうかは問題ではなく、もしスーパーユーザではない人が、mysqld プロセスを Unix アカウントで立ち上げると、警告が出ます。

次の例は、mysqld_multi と使用するオプション ファイルの設定方法について示します。mysqld プログラムが開始または終了する順番は、オプション ファイルで指定する順番によります。グループ番号が完全なシーケンスである必要はありません。例では、最初と 5 番目の [mysqldN] グループは内部的に省略しています。これは、オプション ファイルで 「gaps」 があっても構わないというイラストレーションです。これによって、柔軟性が出ます。

# This file should probably be in your home dir (~/.my.cnf)
# or /etc/my.cnf
# Version 2.1 by Jani Tolonen

[mysqld_multi]
mysqld     = /usr/local/bin/mysqld_safe
mysqladmin = /usr/local/bin/mysqladmin
user       = multi_admin
password   = multipass

[mysqld2]
socket     = /tmp/mysql.sock2
port       = 3307
pid-file   = /usr/local/mysql/var2/hostname.pid2
datadir    = /usr/local/mysql/var2
language   = /usr/local/share/mysql/english
user       = john

[mysqld3]
socket     = /tmp/mysql.sock3
port       = 3308
pid-file   = /usr/local/mysql/var3/hostname.pid3
datadir    = /usr/local/mysql/var3
language   = /usr/local/share/mysql/swedish
user       = monty

[mysqld4]
socket     = /tmp/mysql.sock4
port       = 3309
pid-file   = /usr/local/mysql/var4/hostname.pid4
datadir    = /usr/local/mysql/var4
language   = /usr/local/share/mysql/estonia
user       = tonu

[mysqld6]
socket     = /tmp/mysql.sock6
port       = 3311
pid-file   = /usr/local/mysql/var6/hostname.pid6
datadir    = /usr/local/mysql/var6
language   = /usr/local/share/mysql/japanese
user       = jani

詳細は 項3.3.2. 「オプションファイルの使用」 を参照してください。

4.4. mysqlmanager ? MySQL Instance Manager

mysqlmanager は MySQL Instance Manager (IM) / MySQL インスタンス マネージャです。このプログラムは、MySQL Database Server のインスタンスを監視、管理します。MySQL Instance Manager は Unix のようなオペレーティング システムで利用可能です。Windows でも利用可能で、TCP/IP ポートを使用するデーモンのように動作します。Unix では、Unix ソケット ファイルも監視します。

MySQL Instance Manager は mysqld_safe スクリプトの代わりに使用し、 MySQL Server の 1 以上のインスタンスの開始や停止を行います。Instance Manager は、複数のサーバ インスタンスを管理するため、mysqld_multi スクリプトの代わりとしても使用できます。Instance Manager には次の機能があります。

  • Instance Manager でインスタンスの開始と終了、そしてステータスの報告

  • サーバ インスタンスにはガードあり、またはガードなしで扱える

    • Instance Manager の起動で、ガード インスタンスが立ち上がる。インスタンスがクラッシュすると、Instance Manager がそれを認識し、再起動する。Instance Manager の停止で、インスタンスが終了する。

    • ガードなしのインスタンスは、Instance Manager の起動または、それによる監視が行われている場合は立ち上がらない。起動してからインスタンスがクラッシュする場合、Instance Manager は再起動しない。Instance Manager が停止してもインスタンスが動いていれば、終了しない。

    インスタンスはデフォルトでガードされている。インスタンスは 設定ファイル (コンフィギュレーション) でnonguarded オプションを含めてガードなしと指定できる。

  • Instance Manager で、相互作用インターフェイスを設定インスタンスに与える。それにより、設定ファイルの手動修正の手間が省ける、または削減できる。

  • Instance Manager で、インスタンス管理を遠隔操作できる。これは、MySQL Server のインスタンスを制御したいホストで実行できるという意味であるが、インスタンス管理のオペレーションを実行するリモート ホストから、接続できるという意味でもある。

次のセクションでは、MySQL Instance Manager の操作をより詳しく説明します。

4.4.1. MySQL Instance Manager コマンド オプション

MySQL Instance Manager は数多くのコマンド オプションをサポートしています。簡単な例として、--help オプションで、mysqlmanager を呼び出します。オプションはコマンドラインまたは Instance Manager 設定ファイルで指定します。Windows では、Instance Manager をインストールしたディレクトリのmy.ini が標準設定ファイルです。Unix では、/etc/my.cnf が標準設定ファイルです。異なる設定ファイルを指定するには、Instance Manager を --defaults-file オプションで立ち上げてください。

mysqlmanager は次のリストで説明しているオプションをサポートします。パスワード ファイルでエントリを管理するオプションに関しては、項4.4.4. 「Instance Manager のユーザとパスワード管理」 で説明しています。

  • --help, -?

    ヘルプ メッセージを表示し、終了。

  • --add-user

    新規ユーザをパスワード ファイルに追加する。--username オプションで指定する。(MySQL 5.1.12 での追加)

  • --angel-pid-file=file_name

    エンジェル プロセス (angel process) がプロセス ID に記録するファイル。mysqlmanager がデーモン モードで実行になるときのこと。(すなわち、--run-as-service オプションを与えた場合。) デフォルトのファイル名は mysqlmanager.angel.pid

    --angel-pid-file オプションを与えない場合、デフォルトのエンジェル PID ファイルは、PID ファイルと同じ名前。ただし、PID ファイルの拡張子は、.angel.pid の拡張子と置換。(例: mysqlmanager.pidmysqlmanager.angel.pid となる。)

    (MySQL 5.1.11 での追加)

  • --bind-address=IP

    バインドする IP アドレス。

  • --check-password-file

    パスワード ファイルの正当性 (validity) と整合性 (consistency) をチェックする。(MySQL 5.1.12 での追加)

  • --clean-password-file

    パスワード ファイルからすべてのユーザをドロップする。(MySQL 5.1.12 での追加)

  • --debug=debug_options, -# debug_options

    デバッグ ログを書き込む。debug_options 文字列は、'd:t:o,file_name' というのが通常。(MySQL 5.1.10 での追加)

  • --default-mysqld-path=path

    MySQL Server バイナリのパス。このパスは、設定ファイルのサーバ インスタンス セクションすべてに使用する。この設定ファイルには mysqld-path オプションがない。デフォルトではコンパイル時のパス。これは、MySQL 配布がどのように設定されたかによる。次はその例。--default-mysqld-path=/usr/sbin/mysqld

  • --defaults-file=file_name

    Instance Manager と MySQL Server のセッティングを任意のファイルから読み込む。Instance Manager による設定変更のすべてがこのファイルに書き込まれる。これを使用するときには、コマンドラインで最初のオプションにし、ファイルは存在している必要がある。

    このオプションを使用しない場合、Instance Manager は標準の設定ファイルを使用する。Windows では、Instance Manager をインストールしたディレクトリの my.ini ファイル。Unix では、 /etc/my.cnf が標準ファイル。

  • --drop-user

    新規ユーザをパスワード ファイルからドロップする。--username オプションで指定する。(MySQL 5.1.12 での追加)

  • --edit-user

    パスワード ファイルの既存ユーザ エントリを変更する。--username オプションで指定する。(MySQL 5.1.12 での追加)

  • --install

    Windows では、Instance Manager を Windows のサービスとしてインストールする。サービス名は MySQL Manager

  • --list-users

    パスワード ファイルのユーザをリストする。(MySQL 5.1.12 に追加)

  • --log=file_name

    Instance Manager のログ ファイルのパス。--run-as-service オプションを与えない限り、このオプションの無効。このオプションで指定するファイル名が相対的である場合、ログ ファイルは Instance Manager を立ち上げたディレクトリ下での作成となる。特定のディレクトリで作成できたかどうかを確かめるには、これをフル パスで指す。

    --run-as-service--log なしで与えた場合、ログ ファイルはデータ ディレクトリの mysqlmanager.log になる。

    --run-as-service を与えない場合、ログ メッセージは標準出力へ行く。ログ 出力を獲得するには、Instance Manager 出力をファイルにリダイレクトする。次はその例。

    mysqlmanager > im.log
    
  • --monitoring-interval=seconds

    サーバ インスタンス監視のインターバル (秒)。デフォルトでは、20 秒。Instance Manager は監視対象 (ガード) のインスタンスのそれぞれとの接続を試行するときに、存在していない MySQL_Instance_Manager ユーザ アカウントを使用して、バイタルがあるかどうかをチェックする。接続試行の結果がインスタンスにバイタルがないことを示す場合、Instance Manager はインスタンスを再起動する前に、この試行を何度か実行する。

    通常、MySQL_Instance_Manager アカウントは存在しないため、Instance Manager の接続試行は、監視しているインスタンスから次のようなメッセージをクエリ ログに生成する。

    Access denied for user 'MySQL_Instance_M'@'localhost' ≫
        (using password: YES)
    

    適切なサーバ インスタンス セクションにある nonguarded オプションが特定のインスタンス監視を無効にする。起動してからインスタンスが動かない場合は、Instance Manager はそれを再起動しません。SHOW INSTANCES などで、インスタンスのステータスを要求しない限り、Instance Manager はガードなしのインスタンスとの接続を試行します。

    詳細は、項4.4.5. 「MySQL サーバ インスタンス ステータスの監視」を参照してください。

  • --mysqld-safe-compatible

    mysqld_safe に準拠するマナーで実行。詳細は、項4.4.3. 「MySQL Instance Manager で MySQL Server の起動」 を参照してください。(MySQL 5.1.12 での追加)

  • --password=password, -p password

    パスワード ファイルに、エントリを追加する、また変更するときのパスワードを指定する。これまでの MySQL プログラムの--password/-P オプションとは異なり、パスワードは必須です。オプションではありません。(MySQL 5.1.12 での追加)

  • --password-file=file_name

    Instance Manager がユーザとパスワードを探すファイルの名前。Windows では、 Instance Manager をインストールしたディレクトリの mysqlmanager.passwd がデフォルト。Unix では、/etc/mysqlmanager.passwd がデフォルト ファイル。

  • --pid-file=file_name

    プロセス ID ファイル。Windows では Instance Manager をインストールしたディレクトリの mysqlmanager.pid ファイルがデフォルト。Unix では、データ ディレクトリの mysqlmanager.pid がデフォルト。

  • --port=port_num

    クライアントからのTCP/IP 接続に使用するポート番号。デフォルトのポート番号は、IANA 割り当ての 2273。

  • --print-defaults

    現在のデフォルトを出力し、終了。このオプションを使用するときは、コマンドラインの最初に置く。

  • --print-password-line

    パスワード ファイルへのエントリを準備し、標準出力を表示し、終了する。Instance Manager の出力をファイルへリダイレクトして、そのファイルに保存できる。

    MySQL 5.1.12 前のこのオプションの旧称は --passwd である。

  • --remove

    Windows 環境で、Windows サービスとしての Instance Manager を取り除く。これは、Instance Manager が以前に --install オプションで稼動していたことを前提とする。

  • --run-as-service

    Unix 環境で、デーモン化して、エンジェル プロセスを開始する。エンジェル プロセスは Instance Manager を監視し、クラッシュしたときに、再起動する。エンジェル プロセス自体はシンプルで、クラッシュすることはあまりない。

  • --socket=path

    Unix 環境で、着信する接続に使用するソケット ファイル。デフォルトは /tmp/mysqlmanager.sock 。このオプションは Windows では無意味。

  • --standalone

    Windows で、Instance Manager をスタンド アローン型として稼動するときに使用する。これを指定するときは、Instance Manager をコマンドラインから立ち上げる。

  • --user=user_name

    Unix 環境で、mysqlmanager コマンドを起動実行するときに使用するシステム アカウントのユーザ名。このオプションは警告を出すが、root または名前をつけたユーザで mysqlmanager を立ち上げる場合 (有効なユーザ ID に変更する) を除いて、効果がない。mysqld サーバを実行するときと同じアカウントを使用している場合に、mysqlmanager を組み込むことを推奨。(ここの 「ユーザ」 とは、システム ログインのときのアカウントのことで、権限テーブルの MySQL ユーザのことではない。)

  • --username=user_name, -u user_name

    パスワード ファイルに追加または変更するエントリのユーザ名を指定する。(MySQL 5.1.12 に追加)

  • --version, -V

    バージョン情報を表示して、終了する。

  • --wait-timeout=N

    着信 (incoming) 接続でのアクティビティを閉じる前に待機する秒数。デフォルトでは 28800 秒 (8 時間)。

    MySQL 5.1.7 で追加した。以前は、このタイムアウトは 30 秒で、変更不可だった。

4.4.2. MySQL Instance Manager の設定ファイル

MySQL Instance Manager は、--defaults-file オプションで別のファイルを指定して起動する場合を除き、標準の設定ファイルを使用します。Windows では、Instance Manager をインストールしたディレクトリの my.ini が標準ファイルです。Unix では、/etc/my.cnfが標準ファイルです。

Instance Manager で 設定ファイル (configuration file) の [manager] セクションからオプションと、[mysqld] または [mysqldN] のセクションのオプションを読み取ります。[manager] セクションには、項4.4.1. 「MySQL Instance Manager コマンド オプション」 でリストするオプションがあります。コマンドラインのファースト オプション (最初のコマンド) として与えられているものに関しては別です。次は [manager] オプションのサンプルです。

# MySQL Instance Manager options section
[manager]
default-mysqld-path = /usr/local/mysql/libexec/mysqld
socket=/tmp/manager.sock
pid-file=/tmp/manager.pid
password-file = /home/cps/.mysqlmanager.passwd
monitoring-interval = 2
port = 1999
bind-address = 192.168.1.5

それぞれの [mysqld] または [mysqldN] インスタンス セクションでは、サーバ インスタンスのスタートアップ用に Instance Manager で与えるオプションを指定します。さらに、 [mysqldN] セクションでは、Instance Manager を指定するオプションを含むことができ、これを次にリストしています。このオプションは Instance Manager が解釈し、サーバの起動を試行するときに、サーバへは渡しません。

警告

Instance Manager に特化したオプションは、[mysqld] では使用できません。サーバを Instance Manager を使用せずに立ち上げると、サーバではそのオプションを認識しません。そのため、サーバは正確に起動しません。

  • mysqld-path = path

    mysqld サーバ バイナリのパス。サーバ インスタンスに使用する。

  • nonguarded

    このオプションは、サーバ インスタンスに対する Instance Manager の監視機能を無効化する。デフォルトでは、インスタンスをガードしています。Instance Manager の起動時に、インスタンスも起動する。インスタンス ステータスを監視し、失敗したときは再起動を試行する。Instance Manager の終了時には、インスタンスを停止します。ガードなしのインスタンスの場合には、これらの動作はない。

  • shutdown-delay = seconds

    Instance Manager がシステム終了する前に、サーバ インスタンスを待機する秒数。デフォルトは 35 秒。この待機値を超えると、 Instance Manager は、インスタンスにバイタルがないとみなし、システム終了を試行する。大きなテーブルで InnoDB を使用している場合、この値を大きくする。

インスタンス セクションのサンプルは次の通りです。

[mysqld1]
mysqld-path=/usr/local/mysql/libexec/mysqld
socket=/tmp/mysql.sock
port=3307
server_id=1
skip-stack-trace
core-file
log-bin
log-error
log=mylog
log-slow-queries

[mysqld2]
nonguarded
port=3308
server_id=2
mysqld-path= /home/cps/mysql/trees/mysql-5.1/sql/mysqld
socket     = /tmp/mysql.sock5
pid-file   = /tmp/hostname.pid5
datadir= /home/cps/mysql_data/data_dir1
language=/home/cps/mysql/trees/mysql-5.1/sql/share/english
log-bin
log=/tmp/fordel.log

4.4.3. MySQL Instance Manager で MySQL Server の起動

このセクションでは、サーバ インスタンスが起動するときに、Instance Manager がどのように起動するかについて説明します。Instance Manager を起動する前に、パスワード ファイルを設定する必要があります。これにより、Instance Manager 起動後の制御ができなくなります。Instance Manager アカウントの作成に関する詳細は 項4.4.4. 「Instance Manager のユーザとパスワード管理」 を参照してください。

Unix では、mysqld MySQL データベース サーバは、通常、mysql.server スクリプトで起動します。これは、/etc/init.d/ フォルダにあります。このスクリプトはデフォルトで mysqld_safe を呼び出します。Instance Manager を使用して、[mysql.server] セクションに use-manager を追加して、/etc/my.cnf 設定ファイルを変更することもできます。

[mysql.server]
use-manager

MySQL 5.1.12 前は、Instance Manager ではサーバ インスタンスの一つだけの起動を試行していました。Instance Manager は起動時に設定ファイルがあればそれ読み取り、サーバ インスタンスを検索し、インスタンスのリストを準備します。インスタンス セクションには [mysqld] または [mysqldN] という形式の名前があり、この N は符号なしの整数です。(例: [mysqld1][mysqld2] など。).

インスタンスのリストが整うと、Instance Manager がカードされたインスタンスをリストから起動します。インスタンスがない場合には、Instance Manager は mysqld というインスタンスを作成し、これをデフォルト (コンパイル) の設定値で立ち上げます。これは、Instance Manager をデフォルトの場所でインストールしていないと、mysqld プログラムを検出できないということです。(項2.1.5. 「インストールのレイアウト」 で、MySQL 配布のコンポーネントに関するデフォルトの場所を説明しています。) MySQL を標準ではないところへインストールした場合、Instance Manager の設定ファイルを作成する必要があります。

起動時の動作は mysqld_safe で説明したものと同様に、サーバを立ち上げようとします。しかし、サーバ インスタンスの起動を抑制するような方法で、Instance Manager を実行することは不可能なため、オペレーションによっては柔軟性に欠ける場合があります。たとえば、MySQL のインストーラ を実行するときのような、インスタンスを開始せずに設定するという目的で、Instance Manager を呼び出すことはできません。MySQL 5.1.12 での変更事項は、次の通りです。

  • 新オプション: --mysqld-safe-compatible、MySQL 5.1.12 以前と同様に起動時の動作を Instance Manager にさせる。Instance Manager は [mysqld] インスタンス セクションを設定ファイルで検索し、起動する。Instance Manager が [mysqld] セクションを見つけることができない場合、設定ファイルにアクセス可能であれば、新たに デフォルトの設定値で[mysqld] セクションを書き込む。そして mysqld インスタンスを起動する。Instance Manager は設定ファイル内の別のガード付きインスタンスを立ち上げることもできる。

  • --mysqld-safe-compatible がない場合、Instance Manager はその設定ファイルを読み、ファイルがあれば、そのファイルのガード付きインスタンス セクションでインスタンスを起動する。ファイルがない場合、インスタンスを起動できない。

Instance Manager は、シャットダウン時にすべてのガード付きサーバ インスタンスを終了します。

[mysqldN] サーバ インスタンス セクションで使用できるオプションは、項4.4.2. 「MySQL Instance Manager の設定ファイル」 で説明しています。そこでは、特別の mysqld-path=path-to-mysqld-binary オプションを使用します。これは Instance Manager だけが認識します。このオプションを使用して、Instance Manager に mysqld バイナリがどこにあるかを知らせます。複数のインスタンスがある場合には、datadirport のような別のオプションをセットする必要があります。これは、それぞれのインスタンスに異なるデータ ディレクトリと TCP/IP ポート番号があることを確かめるために行います。項4.12. 「同じマシン上での複数 MySQL サーバの実行」 では、同一のマシンで複数のインスタンスを稼動するときなど、それぞれのインスタンスで、設定値が異なる必要がある場合について説明しています。

警告

[mysqld] インスタンス セクションがある場合は、Instance Manager 特有のオプションを含めないでください。

ySQL Instance Manager を使用する MySQL サーバでの Unix のスタートアップおよびシャットダウンのサイクルは、次の通りです。

  1. /etc/init.d/mysql スクリプトで MySQL Instance Manager を起動する。

  2. Instance Manager がガード付きサーバ インスタンスを立ち上げ、それらを監視する。

  3. サーバ インスタンスの立ち上げに失敗すると、Instance Manager が再起動する。

  4. Instance Manager を /etc/init.d/mysql stop などのコマンドでシステム終了するときに、すべてのサーバ インスタンスが終了になる。

4.4.4. Instance Manager のユーザとパスワード管理

Instance Manager はユーザ情報をパスワード ファイルに保存します。Windows 環境でのデフォルトは、Instance Manager をインストールしたディレクトリの mysqlmanager.passwd です。Unix 環境でのデフォルトは、/etc/mysqlmanager.passwd です。パスワード ファイルを別の場所に指定するには、--password-file オプションを使用します。

パスワード ファイルがない場合、またはパスワードのエントリがない場合、Instance Manager と接続することはできません。

注意

サーバ インスタンスを監視中の Instance Manager は、パスワード ファイルでの変更を認識しません。そのため、システム終了して、パスワード エントリでの変更を行ってから、再起動してください。

パスワード ファイルへのエントリには次の形式があります。ユーザ名と暗号化パスワードの 2 つのフィールドをコロンで区切ります。

petr:*35110DC9B4D8140F5DE667E28C72DD2597B5C848

Instance Manager のパスワード暗号化は、MySQL Server と同じです。一方向操作です。暗号化パスワードの複合化は禁止です。

Instance Manager アカウントは、MySQL Server アカウントとは若干異なります。

これは、クライアントがどのホストからでもユーザ名で Instance Manager に接続可能ということです。この接続を制限し、クライアント接続をローカル ホストだけにするには、--bind-address=127.0.0.1 オプションで、Instance Manager を立ち上げます。これにより、ローカルのネットワーク インターフェースだけを使用するようになります。リモート クライアントからは接続できません。ローカル クライアントは次のように接続します。

shell> mysql -h 127.0.0.1 -P 2273

MySQL 5.1.12 前のパスワード ファイル生成に関するオプションは、--passwd だけで、これは、Instance Manager で ユーザ名とパスワードを指し、その結果を表示するというものです。そして、出力を/etc/mysqlmanager.passwd のパスワード ファイルに保存しています。たとえば、次の通りです。

shell> mysqlmanager --passwd >> /etc/mysqlmanager.passwd
Creating record for new user.
Enter user name: mike
Enter password: mikepass
Re-type password: mikepass

プロンプトで、新規ユーザのユーザ名とパスワードを新たな Instance Manager ユーザとします。そのときは、パスワードを 2 回入力します。画面ではエコーしませんが、2 回入力することで、意図したものとは異なるパスワードの入力を防ぎます。つまり、入力するパスワード、2つが異なる場合、エントリは生成されないということです。

前述のコマンドは、/etc/mysqlmanager.passwd に次のラインを付加します。

mike:*BBF1F551DD9DD96A01E66EC7DDC073911BAD17BA

MySQL 5.1.12 当初、--passwd オプションは、--print-password-line という名前に変更になり、コマンドラインからユーザ アカウント管理のオプションを操作できるようになりました。たとえば、--username--password などのオプションは、アカウント エントリに対するユーザ名とパスワードを指定するときに、コマンドラインで使用できます。これらを使用して、エントリを生成します。シングル ラインのコマンドを入力するなどのプロンプトは不要です。

shell> mysqlmanager --print-password-line
         --username=mike --password=mikepass >> /etc/mysqlmanager.passwd

--username または --password オプションを省略した場合、 Instance Manager が必要な値を指します。

--print-password-line オプションで、Instance Manager の出力はアカウント エントリの結果として送信し、パスワード ファイルへ付加できます。パスワード ファイルで直接操作できるように account-management オプションを Instance Manager に与える方法を次のリストで説明します。オプションは、account-management を目的とした Instance Manager でのスクリプタブル (記述可) です。パスワード ファイル操作を正確に行うには。ファイルが存在し、Instance Manager でアクセスできるようにする必要があります。ただし、--clean-password-file は例外です。これは、存在に関わらず、ファイルを作成します。択一的に、パスワード ファイルがあれば、手動で空ファイルを作成し、Instance Manager だけが読み書き込みするようにアクセス モードと権限を制限します。指定がなければ、デフォルトのパスワード ファイルを使用し、指定するときは、--password-file オプションで指定します。

パスワード フィアル操作での整合性を確証するには、サーバ インスタンスを管理するために使用する Instance Manager のシステム アカウントで ファイルを作成してください。そして、パスワード ファイルのアカウントを管理するときには、そのファイルをそのシステム アカウントから呼び出してください。

  • 新規ユーザの作成

    mysqlmanager --add-user --username=user_name [--password=password]
    

    任意のユーザ名とパスワードをパスワード ファイルに新たなエントリとして加える。--username (または -u) オプション が必要。mysqlmanager でパスワードを指し、これは、--password (または -p) のコマンドラインで与えていないパスワードのこと。ユーザが既に存在していれば、追加できない。

  • 既存ユーザの削除

    mysqlmanager --drop-user --username=user_name
    

    パスワード ファイルのユーザ名のエントリを削除する。ユーザ名が必要。ユーザが存在しなければ、削除できない。

  • 既存ユーザのパスワード変更

    mysqlmanager --edit-user --username=user_name [--password=password]
    

    パスワード ファイルのユーザのパスワードを削除する。ユーザ名が必要。コマンドラインを使用しない場合は、mysqlmanager で呼び出す。ユーザが存在しなければ、変更できない。

  • 既存ユーザのリスト

    mysqlmanager --list-users
    

    このコマンドで、パスワード ファイルのアカウント ユーザ名をリストする。

  • パスワード ファイルのチェック

    mysqlmanager --check-password-file
    

    このコマンドで、パスワード ファイルの整合性と妥当性チェックを行う。このコマンドの失敗は、ファイルに異常があることを示す。

  • パスワード ファイルの空化

    mysqlmanager --clean-password-file
    

    パスワード ファイルを空にする。ファイルにリストされているすべてのユーザを削除する。パスワード ファイルが存在しない場合、このオプションで作成。つまり、このオプションは、別の account-management 操作で使用する新しいパスワード ファイルを作成する。誤ってアカウントを削除しないように、このオプションを使用するときは注意が必要。

4.4.5. MySQL サーバ インスタンス ステータスの監視

ガードしているサーバ インスタンスのステータスを監視では、MySQL_Instance_Manager@localhost というユーザ アカウントで、MySQL_Instance_Manager@localhost というパスワードを使用して、MySQL Instance Manager で接続を試行します。

MySQL Server でこのアカウントを作成する 必要はありません。もともと、存在しないものとして扱われます。Instance Manager では、サーバが操作できる状況にあるかどうかを、サーバの接続できるかどうかで確認し、このアカウントで接続を試行すると、アクセスを拒否し、ログイン エラーを返します。この接続試行はサーバの一般クエリ ログで記録に記録されます。詳細は 項4.11.3. 「一般クエリ ログ」 を参照してください。

SHOW INSTANCES または SHOW INSTANCE STATUS コマンドを使用すると、 ガードがないサーバ インスタンスへの接続試行がInstance Manager で行われます。これは、ガードしていないインスタンスでのみ行うステータス監視です。

サーバ インスタンスが起動に失敗すると、その状態が Instance Manager へ送信られ、それを認識します。インスタンスが起動した後に、クラッシュするという場合は、Instance Manager は、インスタンス の親プロセスであるため、そのサイン (signal) を受信します。

MySQL 5.1.12 から、Instance Manager でインスタンス ステータスを追跡するようになり、どのコマンドをそれぞれのインスタンスに使用できるかを決定します。たとえば、インスタンスの設定を変更するコマンドは、インスタンスがオフラインのときだけ使用可能です。

次のテーブルは、インスタンスのステータスの説明です。ガードしているインスタンスには、どのステータスも該当します。ガードしていないインスタンスは、オンラインまたはオフラインの状態です。スタータス情報は、SHOW INSTANCES または SHOW INSTANCE STATUS コマンドで、status カラムに表示されます。

状態説明
offline未起動、未稼働
starting起動中 (初期化)。ガードなしの場合は、直接オフラインからオンラインになる。
stopping停止中。ガードなしの場合は、直接オフラインからオンラインになる。起動に失敗すればオフラインのまま。
online起動。稼動中。
failedクラッシュしたために、オフラインで Instance Manager が再起動中。またはサーバがまったく起動せず、Instance Manager での再起動が試行中の状態。ガードなしのサーバにこの状態は発生しない。
crashedInstance Manager が接続を試行したが、起動できない。(しばらくしてから、Instance Manager による接続試行が開始される。) ガードなしのサーバにこの状態は発生しない。
abandonedInstance Manager で起動できず、指示があるまで接続試行しない。Instance Manager に再開を指示するには、STOP INSTANCE でオフラインにして、それから START INSTANCE を指示する。設定変更 (configuration) が必要な場合には、サーバをオフラインにしてから、作業を行う。(Instance Manager ではサーバがオフラインのときにだけ、設定変更のコマンドを使用できる。) ガードなしのサーバにこの状態は発生しない。

4.4.6. MySQL Instance Manager へ接続

MySQL Instance Manager では、まずパスワード ファイルをセットアップを行い、それに続いて稼動、接続を行います。MySQL クライアント サーバ プロトコルで、Instance Manager と通信します。たとえば、標準の mysql クライアント プログラムを使用して接続します。

shell> mysql --port=2273 --host=im.example.org --user=mysql --password

Instance Manager での MySQL クライアント サーバ プロトコルは、MySQL 4.1 以降の配布したライブラリとクライアント ツールを使用します。そのため、MySQL C API を使用しているプログラムなどで接続できません。

4.4.7. MySQL Instance Manager のコマンド

MySQL Instance Manager と接続後、コマンドを発行します。コマンドの実行には、次のような原則があります。

  • インスタンス名が有効でない場合、動作しない。

  • インスタンス名が無い (存在しない) 場合、動作しない。 (CREATE INSTANCE は別。)

  • インスタンスが適切なステート (状態) であるよう要求する。オフラインではないインスタンスを設定または起動することはできない。 (MySQL 5.1.12 以降)

  • ファイルが存在しない、または Instance Manager からアクセスできない場合は、設定ファイルの変更はできない。Instance Manager では、内部キャッシュ (メモリ) でインスタンス設定 (コンフィギュレーション) に関する情報を保管している。基本的には、設定ファイルが存在すれば、情報はそこから送られ、コマンドによってはインスタンスの設定を変更できる。

    コマンドで、内部キャッシュ とサーバの設定ファイルのインスタンス セクションの整合性を維持するために、両方を変更 (修正) する。(MySQL 5.1.12 以降。) これを行うには、まずインスタンスがオフラインであること、設定ファイルがアクセス可能であり、不正形式ではないことを確認する。設定ファイルを更新できない場合に、コマンドに失敗すると、キャッシュへの変更がないままとなる。

  • Windows 環境では、 Instance Manager をインストールした ディレクトリの my.ini が標準ファイル。Unix 環境では、/etc/my.cnf が標準の設定ファイル。異なる設定ファイルを指定するには、--defaults-file オプションで Instance Manager を起動する。

  • [mysqld] というインスタンス セクションが設定ファイルには、Instance Manager特有のオプションを入れない。 (項4.4.2. 「MySQL Instance Manager の設定ファイル」 を参照のこと。) つまり、mysqld という名前のインスタンスの設定変更には、これらのオプションを付加しないこと。

次のリストは、使用例とともに、Instance Manager で使えるコマンドを説明します。

  • CREATE INSTANCE instance_name [option_name[=option_value], ...]

    新たなインスタンスを設定する。設定ファイルに、[instance_name] セクションを作成する。インスタンス名が instance_name に対して有効ではない場合、または存在しない場合は、コマンドに失敗する。

    オプションを付けない場合は、インスタンスのセクションを空にする。付ける場合は、オプション ファイルで記述するときと同じ形式にする。使用可能なシンタックスに関しては、項3.3.2. 「オプションファイルの使用」 を参照のこと。複数のオプションを指定する場合は、それらをカンマで区切る。

    例: [mysqld98] という名前のインスタンス セクションを作成するには、変更しようとしている設定ファイルで次のようにする。

    [mysqld98]
    basedir=/var/mysql98
    

    CREATE INSTANCE 経由で同様の効果を与えるには、Instance Manager で次のコマンドを発行する。

    mysql> CREATE INSTANCE mysqld98 basedir="/var/mysql98";
    Query OK, 0 rows affected (0,00 sec)
    

    CREATE INSTANCE でインスタンスを作成するが、起動はしない。

    インスタンス名が、(廃止された) 名前 mysqld である場合には、Instance Manager に対して指定するオプションをオプション リストに含めることはできない。たとえば、nonguarded など。(項4.4.2. 「MySQL Instance Manager の設定ファイル」 を参照のこと。)

    (MySQL 5.1.12 に追加)

  • DROP INSTANCE instance_name

    設定ファイルから instance_name の設定を削除する。

    mysql> DROP INSTANCE mysqld98;
    Query OK, 0 rows affected (0,00 sec)
    

    instance_name が有効なインスタンス名でない場合、あるいは、インスタンスが存在しない、またはオフラインの場合は、コマンドに失敗する。.

    (MySQL 5.1.12 に追加)

  • START INSTANCE instance_name

    オフラインのインスタンスの起動を試行する。非同期 (asynchronous) で、インスタンス起動を待機する。

    mysql> START INSTANCE mysqld4;
    Query OK, 0 rows affected (0,00 sec)
    
  • STOP INSTANCE instance_name

    インスタンス停止を試行する。同期 (synchronous) で、インスタンス停止を待機する。

    mysql> STOP INSTANCE mysqld4;
    Query OK, 0 rows affected (0,00 sec)
    
  • SHOW INSTANCES

    ロードされたすべてのインスタンスの名前とステータスを表示する。

    mysql> SHOW INSTANCES;
    +---------------+---------+
    | instance_name | status  |
    +---------------+---------+
    | mysqld3       | offline |
    | mysqld4       | online  |
    | mysqld2       | offline |
    +---------------+---------+
    
  • SHOW INSTANCE STATUS instance_name

    ステータスとバージョン情報を表示する。

    mysql> SHOW INSTANCE STATUS mysqld3;
    +---------------+--------+---------+
    | instance_name | status | version |
    +---------------+--------+---------+
    | mysqld3       | online | unknown |
    +---------------+--------+---------+
    
  • SHOW INSTANCE OPTIONS instance_name

    インスタンスで使用しているオプションを表示する。

    mysql> SHOW INSTANCE OPTIONS mysqld3;
    +---------------+---------------------------------------------------+
    | option_name   | value                                             |
    +---------------+---------------------------------------------------+
    | instance_name | mysqld3                                           |
    | mysqld-path   | /home/cps/mysql/trees/mysql-4.1/sql/mysqld        |
    | port          | 3309                                              |
    | socket        | /tmp/mysql.sock3                                  |
    | pid-file      | hostname.pid3                                     |
    | datadir       | /home/cps/mysql_data/data_dir1/                   |
    | language      | /home/cps/mysql/trees/mysql-4.1/sql/share/english |
    +---------------+---------------------------------------------------+
    
  • SHOW instance_name LOG FILES

    インスタンスで使用しているすべてのログ ファイルをリストする。結果セットはログ ファイルのパスとサイズ。設定ファイルのインスタンス セクションで、ログ ファイルのパスを指していない場合、(例:log=/var/mysql.log)、Instance Manager が代替するものを検索する。Instance Manager でログ ファイルに代わるものを見つけられないときは、設定ファイルで該当するインスタンス セクションのログ オプションを使用して、明示的にログ ファイルの位置を指定する。

    mysql> SHOW mysqld LOG FILES;
    +-------------+------------------------------------+----------+
    | Logfile     | Path                               | Filesize |
    +-------------+------------------------------------+----------+
    | ERROR LOG   | /home/cps/var/mysql/owlet.err      | 9186     |
    | GENERAL LOG | /home/cps/var/mysql/owlet.log      | 471503   |
    | SLOW LOG    | /home/cps/var/mysql/owlet-slow.log | 4463     |
    +-------------+------------------------------------+----------+
    

    SHOW ... LOG FILES はログ ファイルに関する情報だけを表示する。サーバ インスタンスでログ ファイルを使用する場合には、テーブルに関する情報に関しては表示しない。項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 を参照のこと。

    ログ オプションに関する詳細は 項4.2.2. 「コマンド オプション」 を参照こと。

  • SHOW instance_name LOG {ERROR | SLOW | GENERAL} size[,offset_from_end]

    指定したログ ファイルを部分的に取り出す。多くのユーザは最新のログ メッセージに関心があるため、size パラメータは最後のログから読み出すバイト数を定義する。ログ ファイルの途中からデータを読み出すには、任意の offset_from_end パラメータを指定する。次の例では、21 バイトのデータを読み出し。ログ ファイルの終わりから 23 バイト前で始まり、2 バイト前で終わる。

    mysql> SHOW mysqld LOG GENERAL 21, 2;
    +---------------------+
    | Log                 |
    +---------------------+
    | using password: YES |
    +---------------------+
    
  • SET instance_name.option_name[=option_value]

    特定インスタンスの設定セクションを変更する。インスタンス オプションを変更または追加するため。このセクションに追加したオプションは、まだ現在していないオプションのこと。それ以外では新たなセッティングが既存のものとの置き換えになる。

    mysql> SET mysqld2.port=3322;
    Query OK, 0 rows affected (0.00 sec)
    

    MySQL 5.1.12 以降、カンマ区切りで、複数のオプションを指定することができるようになり、オフラインのインスタンスに SET を使用できる。それぞれのオプションがインスタンス名を示すようにする。

    mysql> SET mysqld2.port=3322, mysqld3.nonguarded;
    Query OK, 0 rows affected (0.00 sec)
    

    MySQL 5.1.12 前は、指定できるオプションが 1 つだけで、設定ファイルへの変更は、MySQL サーバが再起動するまで効果を発揮しない。また、変更はインスタンス管理をするローカル キャッシュには保存されず、FLUSH INSTANCES コマンドを実行するまで有効にならない。

  • UNSET instance_name.option_name

    インスタンスの設定セクションからオプションを削除する。

    mysql> UNSET mysqld2.port;
    Query OK, 0 rows affected (0.00 sec)
    

    MySQL 5.1.12 以降、カンマ区切りで、複数のオプションを指定することができるようになり、オフラインのインスタンスに UNSET を使用できる。それぞれのオプションがインスタンス名を示すようにすること。

    mysql> UNSET mysqld2.port, mysqld4.nonguarded;
    Query OK, 0 rows affected (0.00 sec)
    

    MySQL 5.1.12 前は、指定できるオプションは 1 つだけで、設定ファイルへの変更は、MySQL サーバが再起動するまで効果を発揮しない。また、変更はインスタンス管理をするローカル キャッシュには保存しないため、FLUSH INSTANCES コマンドを実行するまで有効にならない。

  • FLUSH INSTANCES

    MySQL 5.1.12 以降、FLUSH INSTANCES をすべてのインスタンスをオフラインにしてから使用する。このコマンドで Instance Manager に設定ファイルを再読み込みさせ、内部メモリのコンフィギュレーション キャッシュを更新 (update) し、ガード インスタンス (ガード有り) を起動する。

    MySQL 5.1.12 前では、Instance Manager に設定ファイルの読み込みと内部ストラクチャのリフレッシュを強制している。設定ファイルを編集してからこのコマンドを実行するが、インスタンスの再起動はできない。

    mysql> FLUSH INSTANCES;
    Query OK, 0 rows affected (0.04 sec)
    

    FLUSH INSTANCES は廃止。MySQL 5.2 で削除。

4.5. インストール関連プログラム

4.5.1. make_win_bin_dist ? Package MySQL 配布 (ZIP アーカイブ)

実行可能なプログラム作成で、ソースから MySQL 配布を構築した後の Windows 環境でのスクリプトです。バイナリとサポート ファイルを ZIP ファイルのパッケージです。これを MySQL をインストールする場所で解凍します。

make_win_bin_dist はシェル スクリプトですので、使用するには Cygwin をインストールしておく必要があります。

このプログラムは変更する可能性がありますが、現在は、ソース配布の root ディレクトリから、次のように呼び出します。

shell> make_win_bin_dist [options] package_basename [copy_def ...]

package_basename 引数が ZIP ファイルのベース名になります。ファイルを解答したときに、ディレクトリの名前になります。

別のビルドからファイルを取り込む場合は、次に示すスクリプトを使用して、対象ファイルをコピーします。これは relative_dest_name=source_namecopy_def 引数経由です。

例:

bin/mysqld-max.exe=../my-max-build/sql/release/mysqld.exe

ディレクトリを指定するときは、ディレクトリ全体がコピーの対象になります。

make_win_bin_dist でオプションを認識します。そのオプションは次の通りです。

  • --debug

    デバッグ バイナリを梱包し、構成できなかった場合にはエラーを生成。

  • --embedded

    埋め込みサーバを梱包し、構成できなかった場合にはエラーを生成。デフォルトは構成したら梱包という設定。

  • --exe-suffix=suffix

    mysql バイナリのベース名にサフィックスを付ける。例: -abc というサフィックスで、mysqld-abc.exe というバイナリになる。

  • --no-debug

    構成できていたとしても、デバッグ バイナリを梱包しない。

  • --no-embedded

    構成できていたとしても、埋め込みサーバを梱包しない。

  • --only-debug

    構成したものが Debug を対象としているときに使用するオプション。通常のバイナリをデバッグ バージョンと交換したい場合などに使用する。従って、分けている debug ディレクトリ には使用しない。

4.5.2. mysql_fix_privilege_tables ? MySQL システム テーブルのアップグレード

MySQL のリリースによっては、新たに権限を追加するとき、または新たな機能をサポートするときに、mysql データベースのシステム テーブルのストラクチャを変更できます。新しいバージョンの MySQL にアップグレードするときは、システム テーブルも同様に更新し、ストラクチャが最新であることを確かめる必要があります。これをしないと、この利点を活用できません。まず、mysql データベースをバックアップし、次の手順に従います。

ノート:MySQL 5.1.7 以降は mysql_upgrade を使用してください。mysql_fix_privilege_tables と mysql_upgrade と置き換わりました。 項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照こと。

Unix または Unix のようなシステム環境では、mysql_fix_privilege_tables スクリプトでシステム テーブルを更新します。

shell> mysql_fix_privilege_tables

このスクリプトはサーバが稼動しているときに実行してください。ローカル ホストでroot で稼動しているサーバに接続するためです。root アカウントでパスワードが必要な場合には、コマンドラインで次のようにパスワードを指します。

shell> mysql_fix_privilege_tables --password=root_password

mysql_fix_privilege_tables スクリプトは、必要に応じて現行のフォーマットに合わせてシステム テーブルを変換するアクションを行います。実行中に Duplicate column name という警告がでることがありますが、これは無視します。

スクリプトを実行後、サーバをシステム終了し、再起動します。

Windows システム環境では、 MySQL 配布に、mysql_fix_privilege_tables.sql という SQL スクリプトが含まれていて、これは、mysql のクライアントを使用して実行します。たとえば、MySQL を C:\Program Files\MySQL\MySQL Server 5.1 でインストールした場合のコマンドは次のようになります。

C:\> cd "C:\Program Files\MySQL\MySQL Server 5.1"
C:\> bin\mysql -u root -p mysql
mysql> SOURCE scripts/mysql_fix_privilege_tables.sql

mysql コマンドで、root のパスワード入力を指示されたら、パスワードを入力します。

インストールした場所が別のディレクトリである場合は、適宜パスを調整します。

Unix の手順では、mysqlmysql_fix_privilege_tables.sql のステートメントの処理中に、Duplicate column name という警告が出ますが、これは無視します。

スクリプトを実行後、サーバをシステム終了し、再起動します。

4.5.3. mysql_install_db ? MySQL データ ディレクトリ 初期化スクリプト

mysql_install_db は MySQL データを初期化し、システム テーブルを作成します (システム テーブルがない場合)。MySQLサーバとしての mysqld は起動後にデータ ディレクトリのデータにアクセスする必要があります。そのため、mysqld を実行するのと同じアカウントで mysql_install_db を起動するか、または root で立ち上げて、--user オプションを使用して、mysqld を実行するユーザ名を指します。

mysql_install_db を呼び出すには、次のシンタックスを使用します。

shell> mysql_install_db [options]

mysql_install_dbmysqld を呼び出します。これには、--bootstrap--skip-grant-tables を使用します。(項2.9.2. 「典型的な configure オプション」 参照。) MySQL を --disable-grant-options オプションで構成した場合、--bootstap--skip-grant-tables のオプションは無効化します。この処理には、すべてのオプションを有効化したフル パスとサーバに、 MYSQLD_BOOTSTRAP 環境変数をセットします。mysql_install_db はそのサーバを使うようになります。

mysql_install_db では次のオプションをサポートします。

  • --basedir=path

    基準パス。MySQLをインストールしているディレクトリを指す。

  • --force

    DNS では機能しない場合に、mysql_install_db で実行します。この場合、通常使用している権限テーブルのエントリのホスト名は IP アドレスになります。

  • --datadir=path, --ldata=path

    MySQL データ ディレクトリへのパス。

  • --rpm

    内部使用。MySQL インストール プロセス中の、RPM ファイルのオプション。

  • --skip-name-resolve

    権限テーブルのエントリで、ホスト名ではなく、IP アドレスを使用する。DNS が機能しない場合に使用するオプション。

  • --srcdir=path

    内部使用。 mysql_install_db で、エラー メッセージやぺルプ テーブルのファイルなど、サポート ファイルを検索するときのディレクトリ。(MySQL 5.1.14 での追加)

  • --user=user_name

    mysqld を実行するときのログイン ユーザ名。このユーザで、mysqld で作成するファイルやディレクトリの操作を行う。このオプションを使用するときは、root であることが必要。デフォルトでは、ログイン中の名前で mysqld が動作し、ファイルやディレクトリはそのログイン ユーザの所有となる。

  • --verbose

    冗長モード。プログラム実行に関する情報を出力する。

  • --windows

    内部使用。Windows 配布を作成するときに使用するオプション。

4.5.4. mysql_upgrade ? MySQL アップグレードのテーブル チェック

MySQL のアップグレードでは、その度に、mysql_upgrade を実行します。これにより、データベース内のテーブルにおける最新の MySQL Server との互換性をチェックすることができます。該当テーブルが非互換の場合は、チェックの対象になり、問題があれば、そのテーブルを修正します。mysql_upgrade コマンドは、システム テーブルのアップグレードも行うため、新たな権限と追加機能を使用できるようになります。

チェックと修正が済んだテーブルは、最新のMySQL バージョン番号とマーク (特徴付け) される。これにより、次に同じバージョンのサーバで mysql_upgrade を立ち上げるときに、そのテーブルをチェックして修正する必要があるかどうかを確かめる必要がなくなります。

mysql_upgrade では、データ ディレクトリの mysql_upgrade.info というファイルに MySQL のバージョン番号も保存します。これは、すべてのテーブルがチェック済みであるかどうかを簡単に調べます。これにより、リリースでテーブル チェックをスキップするようになります。ファイルを無視するには、--force オプションを使用します。

テーブル チェックおよび修復、システム テーブルのアップグレードを行なうには、mysql_upgrade で次のコマンドを実行します。

mysqlcheck --check-upgrade --all-databases --auto-repair
mysql_fix_privilege_tables

mysql_upgrade コマンドは、古い方、つまり mysql_fix_privilege_tables より優先です。MySQL 5.1.7 では、シェル スクリプト として mysql_upgrade が加えられ、Unix システムだけで機能します。MySQL 5.1.10 以降は、mysql_upgrade は実行可能なバイナリとして、すべてのシステムで使用できます。mysql_upgrade をサポートしているものより古いシステムでは、手動で mysqlcheck コマンドを実行し、システム テーブルのアップグレードを行ないます。詳細は 項4.5.2. 「mysql_fix_privilege_tables ? MySQL システム テーブルのアップグレード」 を参照してください。

何がチェックされるか、に関する詳細は、CHECK TABLE ステートメントの FOR UPGRADE オプションに関する説明を参照してください。(項12.5.2.3. 「CHECK TABLE 構文」)

mysql_upgrade を使用するには、サーバが起動していることを確認し、次のように呼び出します。

shell> mysql_upgrade [options]

mysql_upgrade はコマンドライン、およびオプション ファイルの [mysql_upgrade] グループからオプションを読み取ります。これは次のオプションをサポートします。

  • --help

    ショート ヘルプ メッセージを表示し、終了。

  • --basedir=path

    基準パス。MySQLがインストールされているディレクトリを指す。

  • --datadir=path

    データ ディレクトリへのパス。

  • --force

    mysqlcheck を強制実行する。最新の MySQL バージョンで mysql_upgrade を既に実行している場合も。つまり、このオプションは、mysql_upgrade.info を無視するようにする。

  • --user=user_name, -u user_name

    サーバに接続するときの MySQL ユーザ名。デフォルト名は root

  • --verbose

    冗長モード。プログラム実行に関する情報を出力する。

他のオプションは、mysqlcheck および mysql_fix_privilege_tables へ渡される。たとえば、--password[=password] オプションは指定しなければならない可能性がある。

4.5.5. mysql_tzinfo_to_sql ? タイム ゾーン テーブルのロード

mysql_tzinfo_to_sql は、mysql データベースに、タイム ゾーン テーブルをロードするプログラムです。zoneinfo データベース (タイム ゾーンを記述するファイルのセット) があるシステムで使用します。たとえば、Linux、 FreeBSD、 Sun Solaris、 Mac OS X などです。一般的なファイル位置は /usr/share/zoneinfo です。zoneinfo データベースがないシステムの場合には、項4.10.8. 「MySQL サーバのタイム ゾーン サポート」 で説明するパッケージをダウンロードします。

mysql_tzinfo_to_sql はいくつかの方法で呼び出せます。

shell> mysql_tzinfo_to_sql tz_dir
shell> mysql_tzinfo_to_sql tz_file tz_name
shell> mysql_tzinfo_to_sql --leap tz_file

最初の起動シンタックス (invocation) では、mysql_tzinfo_to_sql に zoneinfo ディレクトリのパスを渡し、出力を mysql プログラムに送ります。次はその例です。

shell> mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql

mysql_tzinfo_to_sql はシステム内のタイム ゾーン ファイルを読み、そこから SQL ステートメントを生成します。mysql でそのステートメントが処理され、タイム ゾーン テーブルにロードされます。

2 番目のシンタックスは mysql_tzinfo_to_sql を タウム ゾーン名 tz_name に関連するシングル タイム ゾーン ファイル tz_file にロードします。

shell> mysql_tzinfo_to_sql tz_file tz_name | mysql -u root mysql

タイム ゾーンで、リープ秒のカウントが必要な場合は、mysql_tzinfo_to_sql を 3 番目のシンタックスを使用して呼び出して、リープ秒情報を初期化します。tz_file は使用しているタイム ゾーン ファイルの名前です。

shell> mysql_tzinfo_to_sql --leap tz_file | mysql -u root mysql

4.6. セキュリティ問題

このセクションでは、MySQL のインストールすることによる外部攻撃、または不正使用に対するセキュリティを高めるために理解が必要なセキュリティ事項に関して説明します。MySQL を使用したユーザ アカウントのセットアップやデータベースアクセスへのチェックなど、コントロール システムへのアクセスに関する詳細は 項4.7. 「MySQL アクセス権限システム」 も参照してください。

MySQL での SQL サーバのセキュリティに関する QA は、項A.10. 「MySQL 5.1 FAQ ? Security」 を参照してください。

4.6.1. セキュリティ ガイドライン

インターネットに接続しているコンピュータで MySQL を使用するには、このセクションの内容を十分に理解し、セキュリティ面での誤操作を起こさないように注意してください。

セキュリティに関する説明では、様々な攻撃に対して、MySQL サーバだけでなく、サーバ ホスト全体を完全に守る必要があることを強調しています。この攻撃とは、聴傍受、改ざん、再生、サービス妨害などのことです。ここでは、可用性および耐障害性のすべてについては触れていません。

MySQL では、接続、クエリ、そしてユーザが行なう別のオペレーションに対して、アクセス制御リスト (ACL, Access Control Lists) に基づくセキュリティ保護を行ないます。MySQL クライアントとサーバ間での SSL 暗号化接続をサポートしています。ここで説明するコンセプトの多くは、MySQL だけに該当するものではなく、様々なアプリケーションにも該当します。

MySQL を実行するときには、常に次のガイドラインに従います。

  • MySQL root ユーザ以外のだれにも mysql データベースの user テーブルへのアクセス権を与えない。 これは特に重要なことです。

  • MySQL のアクセス権限システムについて学び、理解する。MySQL へのアクセスを制御するには、GRANT および REVOKE のステートメントを使用します。必要以上の権限をユーザに設定しないこと。すべてのホストに対する権限は決して与えないこと。

    チェックリスト

    • mysql -u root を試す。パスワードなしでサーバに正常に接続できるようだと問題がある。この場合、すべての権限を持つ root ユーザとして、MySQL サーバに接続できるということである。特に root パスワードの設定に関する項目に注意して、MySQL インストール手順を見直す。項2.10.3. 「最初の MySQL アカウントの確保」 を参照のこと。

    • SHOW GRANTS コマンドを使用して、だれが何にアクセスできるかをチェックする。REVOKE コマンドを使用して不要な権限を削除する。

  • データベースには、テキスト形式のパスワードを保存しないこと。コンピュータがクラックされたとき、パスワードの完全なリストが奪われて不正使用される結果になる。MD5()SHA1()、または別の一方向ハッシング関数を使用する。

  • 辞書を使用してパスワードを選択しない。特殊プログラムで解読されてしまう。「xfish98」 のようなパスワードも良くない。標準 QWERTY キーボードで 「fish」 を 1 列左でタイプした 「duag98」 などを推奨。また、「Mary had a little lamb」 の頭文字を取って 「Mhall」 とするのも良い。 この方法だと覚えやすく、また部外者が類推することも困難。

  • ファイアウォールに投資する。これにより、少なくとも 50% の攻撃を防ぐことができる。MySQL をファイアウォール内つまり非武装地帯 (DMZ) に配置する。

    チェックリスト

    • nmap などのツールを使用して、インターネットから自分のポートをスキャンしてみる。MySQL はデフォルトでポート 3306 を使用する。このポートは、信頼されていないホストからアクセスできてはいけない。他にも、MySQL ポートが開いているかどうか確かめる簡単な方法として、リモート コンピュータから以下のコマンドを実行するという方法がある。ここで、server_host は MySQL サーバのホスト名、または IP アドレスである。

      shell> telnet server_host 3306
      

      接続できて意味不明な文字が返ればポートが開いている。開いておく正当な理由がない限り、ファイアウォールまたはルータで閉じておく。telnet がハングするか、接続が拒否されれば正常である。つまり、ポートは閉じている。

  • ユーザが入力するデータを信頼しないこと。Web フォーム、URL、その他のアプリケーションから特殊文字またはエスケープ文字シーケンスが入力され、不正操作が行われる可能性がある。ユーザが 「; DROP DATABASE mysql;」 などのような入力をしても、アプリケーションが安全に保たれるようにしなければならない。これは極端な例であるが予防策を講じておかないと、クラッカーによる同様の手段によって、重大なセキュリティリークやデータの紛失が発生する可能性がある。

    また、数値データもチェックすること。数値定数をアポストロフィで囲むこと。SELECT * FROM table WHERE ID=234 ではなく、SELECT * FROM table WHERE ID='234' のようにする。(ユーザが 234 という値を入力したときに、SELECT * FROM table WHERE ID=234 というようなクエリをアプリケーションで生成する場合、そのユーザが 234 OR 1=1 という値を入力して、そのアプリケーションで SELECT * FROM table WHERE ID=234 OR 1=1 というクエリを生成させることができる。その結果、サーバがテーブルの行をすべて読み出してしまい、サーバの負荷が増える。) MySQL は自動的のこの文字列を数値に変換し、非数値記号を削除する。

    文字列だけを保護するのは、よくあるミスである。公開データのみのデータベースは保護する必要がないという考えもよくある誤りである。そのようなデータベースにも、サービス妨害タイプの攻撃 ( DoS攻撃) が可能であり、前述の例は、そのようなテクニックを不正使用したケースであり、これによるサーバの脆弱性をつかれ、システム ダウンに繋がる。(正当なユーザに対してサービスを提供できなくなる。)

    チェックリスト

    • すべての Web フォームで 、‘'’ および ‘"’を入力してみる。何らかの MySQL エラーが発生した場合は、すぐにその問題を調べる。

    • URL で %22 (‘"’)、 %23 (‘#’)、および %27 (‘'’) を追加して URL の動的修正を試みる。

    • 前述の文字を含む URL の動的 データを数値型から文字型に変更する。この類の攻撃があってもアプリケーションに影響しないようにする。

    • 数値フィールドに数値ではなく、文字、スペース、および特殊記号を入力してみる。MySQL に渡すことなくアプリケーションがそれらの値を削除するか、エラーを生成することが必要である。値がチェックされずに MySQL に渡ると非常に危険である。

    • MySQL に渡す前にデータサイズをチェックする。

    • 管理目的で使用するユーザ名とは別のユーザ名で、アプリケーションをデータベースに接続させる。アプリケーションに、必要以上のアクセス権を設定しないこと。

  • 様々なアプリケーション プログラムのインターフェースは、データ値に特殊文字をエスケープする手段になる。適切に使用しなければ、アプリケーションのユーザによる入力が原因で、意図したものとは異なる効果を与えるステートメントの生成を回避できる。

    • MySQL C API: mysql_real_escape_string() API コールを使用する。

    • MySQL++: クエリのストリームには escape または quote などの修飾子を使用する。

    • PHP: PHP 4.3.0以降 は、mysql_real_escape_string() 関数を使用する。PHP 4.3.0前の PHP バージョンでは、mysql_escape_string() を使用して、PHP 4.0.3 以前は、addslashes() を使用する。ノート: mysql_real_escape_string() 関数だけが認識文字セット。そのほかの関数は、無効なマルチ バイトの文字セットを使用すると、「擦り抜ける (bypassed) 」。PHP 5 では、mysqli という拡張モジュールを使用する。これは、改善を施した MySQL の認識プロトコルとパスワード、プレースホルダの準備されたステートメント (prepared statements) をサポートする。

    • Perl DBI: プレースホルダ、または quote() メソッドを使用する。

    • Ruby DBI: プレースホルダ、または quote() メソッドを使用する。

    • Java JDBC: PreparedStatement オブジェクトとプレースホルダ を使用する。

    別のプログラミングのインターフェイスでも上記と同様の役割がある可能性がある。

  • 暗号化していないプレーンのデータをインターネット経由で送らない。インターネット経由の情報は、時間と技術があれば誰にでもアクセスでき、第三者によって悪用される可能性がある。MySQL では、バージョン 4.0. 以降、内部 SSL 接続をサポートしている。 SSH ポート転送を使用して、暗号化(および圧縮)された通信トンネルを作成できる。

  • tcpdumpstrings などのユーティリティの使用法を理解すること。ほとんどの場合、以下のようなコマンドで、MySQL データ ストリームが暗号化されているかどうかをチェックできる。

    shell> tcpdump -l -i eth0 -w - src or dst port 3306 | strings
    

    これは、Linux システムで有効。他のシステムでも、少し修正するだけで使用できる。 警告: データを見ることができなくても、必ずしも実際に暗号化されているとは限らない。高度なセキュリティが必要な場合は、専門家に相談する。

4.6.2. MySQL のクラッカー対策

MySQL サーバに接続するときは、パスワードを使用します。MySQL 4.1.1 以降、クライアント接続中のパスワード処理に関して、より高度なセキュリティでグレードアップしています。パスワードは平文テキストでは送信していませんが、MySQL 4.1 より前のバージョンでの暗号化アルゴリズムは、新バージョンで採用しているパスワード形式ほど強力なものではありません。そのため、古いパスワード形式を使用している場合は、クライアントとサーバ間のトラフィックを盗聴できれば、クラッカーは少しの努力でパスワードを探り当てることができる可能性があります。パスワードのメカニズムに関しては、項4.7.9. 「MySQL 4.1 のパスワードハッシュ」 を参照してください。

MySQL Enterprise The MySQL Network Monitoring and Advisory Service では、サーバ セキュリティの強化に関する情報を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

パスワード以外の情報はテキスト形式で送信されているため、第三者によって内容を読み盗られる可能性があります。クライアントとサーバ間の接続が信用できないネットワークを経由する場合に、この可能性を懸念するときは、解読が困難な圧縮プロトコルを使用します。接続時のセキュリティをさらに高めるには、MySQL の内部 SSL サポートを使用します。(項4.8.7. 「接続安全」 を参照のこと。) 別の方法としては、MySQL サーバと MySQL クライアント間で暗号化 TCP/IP 接続に SSH を利用することも可能です。Open Source SSH クライアントは http://www.openssh.org/を、商用の SSH クライアントは、http://www.ssh.com/ をそれぞれ参照してください。

MySQL システムのセキュリティを確保するためには、以下の事項を強く推奨します。

  • すべての MySQL ユーザにパスワードを使用する。クライアント プラグラム側では、そのプログラムを実行してる者が誰であるのかを知る必要はなく、クライアント/サーバ型のアプリケーションにおいては、クライアント側で任意のユーザ名を指定できるのが一般的である。たとえば、別の者が接続に mysql プログラムを簡単に使用することができ、つまり、other_user にパスワードが設定されていなければ、だれでも mysql -u other_user db_name として簡単に他人になりすましてログインできる。すべてのユーザにパスワードを使用すれば、他人のユーザ名で接続することが困難になる。

    パスワードのセッティング方法に関する記述は、項4.8.5. 「パスワードの設定」 を参照のこと。

  • MySQL サーバ (デーモン) を Unix root アカウントで実行しないこと。これを行なうと、FILE 権限のあるユーザであれば誰でも root (例: ~root/.bashrc)としてファイルを作成できてしまうので、非常に危険である。これを防ぐために、--user=root オプションを使用して直接指定された場合を除き、mysqldroot として実行することを拒否するようになっている。

    mysqld は、普通のユーザ、つまり権限なしのユーザで実行できる。新しい Unix アカウント mysql を作成してさらにセキュリティを高めることができ、これを、MySQL 管理専用のアカウントとする。別の Unix アカウントで mysqld を開始するには、サーバのデータディレクトリにある my.cnf オプション設定ファイルの [mysqld] グループに、アカウント名を指定する user 行を追加する。次に例を示す。

    [mysqld]
    user=mysql
    

    これで、サーバを手動で起動した場合も、mysqld_safe または mysql.server を使用して起動した場合でも、指定のアカウントでサーバが起動する。詳細は 項4.6.5. 「ユーザによる MySQL の実行」 を参照のこと。

    mysqldroot ではない Unix ユーザで実行するということは、user テーブルで root というユーザ名を変更する必要がある、という意味ではない。MySQL アカウントのユーザ名と、 Unix アカウントにはお互い何の関係もない。

  • テーブルへのシンボリック リンクをサポートしない。(これは --skip-symbolic-links オプションで無効にできる)。このことは、rootmysqld を実行する場合、mysqld サーバ データ ディレクトリへの書き込み権限があるユーザであれば誰でも、システムのすべてのファイルを削除できることになるので、特に重要である。項6.6.1.2. 「Unix 上のテーブルに対するシンボリックリンクの使用」 を参照のこと。

  • mysqld を実行する Unix アカウントだけに、データベース ディレクトリの読み取り権限と書き込み権限があることを確認する。

  • PROCESS または SUPER の権限を管理側ユーザには以外には与えない。mysqladmin processlistSHOW PROCESSLIST の出力には、現在実行中のクエリのテキストが表示される。そのため、これらコマンドを実行できるユーザは、UPDATE user SET password=PASSWORD('not_secure') などのクエリを実行して、サーバ プロセス リストを開示してしまう可能性がある。

    mysqld は、SUPER 権限を持つユーザ用に特別接続枠を予約しているので、すべての通常接続が使用中の場合でも、MySQL root ユーザはログインしてサーバの状態をチェックできる。

    SUPER 権限はクライアント接続を中断でき、システム変数を変更することでサーバのオペレーションを変更し、さらに、レプリケーション サーバもコントロールする。

  • FILE 権限をすべてのユーザには与えない。この権限を持つユーザは、mysqld デーモンの権限でファイルシステムのどの場所にでもファイルを書き込める。安全対策として、SELECT ... INTO OUTFILE で生成されるファイルについてはだれでも書き込み可能だが、既存のファイルには書き込めないようになっている。

    FILE 権限は、サーバを実行している Unix ユーザがアクセスできるすべての読み取り可能ファイルを読む場合にも使用できる。また、ユーザが何らかの権限を持っているカレントデータベースに任意のファイルを読み込むことができる。 つまり、不正使用される可能性がある。たとえば、LOAD DATA を使用して /etc/passwd をテーブルにロードし、SELECT で読むことができる。

  • DNS を信頼しない場合、権限テーブルで、ホスト名ではなく IP アドレスを使用すること。いずれにしても、ワイルド カードを含むホスト名を使用して権限テーブルを作成する際には特に注意が必要である。

  • 単一ユーザの接続数を制限する場合は、mysqldmax_user_connections 変数を設定する。 GRANT ステートメントでも、ユーザへのサーバ接続を制限するリソース コントロール オプションがある。項12.5.1.3. 「GRANT 構文」 を参照のこと。

4.6.3. セキュリティ関連の mysqld オプション

次の mysqld オプションはセキュリティに影響します。

  • --allow-suspicious-udfs

    メイン関数しか持っていないユーザ定義関数をロードすることが出来るかどうかを制御する。(xxxという名前のユーザ関数を定義するとき。) デフォルトでは、このオプションはオフで、少なくとも一つの追加関数を持ったユーザ定義関数だけをロードできる。これによって、不正なユーザ定義関数がロードされる危険性を防ぐ。詳細は 項25.3.4.6. 「User-Defined Function Security Precautions」 を参照。

  • --local-infile[={0|1}]

    --local-infile=0 を使用すると、クライアントで LOAD DATA ステートメントの LOCAL を使用できなくなる。 項4.6.4. 「LOAD DATA LOCAL のセキュリティ関連事項」 を参照のこと。

  • --old-passwords

    新たなパスワードに古いパスワード形式でのハッシュの生成を強制する。(MySQL 4.0 以前のパスワードを強制する。) これは、サーバが古いクライアント プログラムをサポートする必要がある場合に有用である。詳細は 項4.7.9. 「MySQL 4.1 のパスワードハッシュ」 を参照。

  • --safe-show-database (OBSOLETE)

    前バージョンの MySQL では、このオプションが SHOW DATABASES ステートメントに影響し、どのユーザにどのような権限が与えられているかを示すデータベース名を表示していた。MySQL 5.1 では、このオプションはデフォルトで使用不可としています。 ユーザ毎にデータベース名へのアクセスを制御することができるものは SHOW DATABASES 権限が存在します。項12.5.1.3. 「GRANT 構文」 を参照のこと。

  • --safe-user-create

    このオプションが有効になっている場合、ユーザに mysql.user テーブルへの INSERT 権限がなければ、そのユーザは GRANT コマンドを使用して新規 MySQ Lユーザを作成できない。事前設定された権限で新規ユーザを作成できるようにするには、対象ユーザに以下の権限を設定する。

    GRANT INSERT(user) ON mysql.user TO 'user_name'@'host_name';
    

    これで、ユーザは権限カラムを直接変更できないが、GRANT コマンドを使用して他のユーザに権限を与えることができるようになる。

  • --secure-auth

    4.1 より前のパスワードでのアクセスを認証しない。

    mysql クライアントには、--secure-auth オプションもあり、これは、サーバがそのクライアントに対して古い形式のパスワードを要求する場合に、サーバへの接続を拒否する。

  • --skip-grant-tables

    サーバが一切の権限システムを使用しないようにする。これによりすべての人が、すべてのデータベースにアクセスできる ようになる。実行中のサーバに権限テーブルの使用を再開するには、mysqladmin flush-privileges または mysqladmin reload をシステム シェルから実行する。またはサーバ接続後に MySQL FLUSH PRIVILEGES ステートメントを発行する。このオプションは、プラグインとユーザ定義関数 (UDF) のロードを抑圧する。

  • --skip-merge

    MERGE ストレージ エンジンを無効化する (MySQL 5.1.12 での追加)。ユーザに MyISAM テーブル t にアクセスできる場合に、そのユーザが、t へアクセスする MERGE テーブル m を作成できる。しかし、t でのこのユーザ権限が連続して呼び出だすときは、m を経由して、t へアクセスを継続できる。

  • --skip-name-resolve

    ホスト名を決定できない。権限テーブルの Host カラム値すべてが、IP アドレスまたは localhost である必要がある。

  • --skip-networking

    TCP/IP 経由の接続を認めない。mysqld への接続をすべて Unix ソケットで行う。

  • --skip-show-database

    ユーザが SHOW DATABASES 権限を持っていない場合に、SHOW DATABASES コマンドを無効にする。ステートメントはすべてのデータベース名を表示する。このオプションをセットしない場合、SHOW DATABASES はすべてのユーザが利用できるようになるが、ユーザが SHOW DATABASES 権限、またはそのデータベースに関する何らかの権限を持っているときには、それぞれのデータベース名だけが表示される。注意:すべての グローバル権限がデータベースに対する権限として扱われる。

  • --ssl*

    --ssl で始まるオプションで、SSL経由での接続をクライアントに許可するかどうかを指定し、SSL キーと証明書 がどこにあるかを示す。詳細は 項4.8.7.3. 「SSL コマンド オプション」 を参照。

4.6.4. LOAD DATA LOCAL のセキュリティ関連事項

LOAD DATA ステートメントはサーバ ホストに置かれているファイルをロードできます。または LOCAL キーワードが指定された場合に、クライアント ホストに位置するファイルをロードできます。

LOAD DATA ステートメントのLOCAL バージョンのサポートに関しては、潜在的な問題が 2 つあります。

  • ファイルの読み取りがサーバ側から開始される。そのため、理論的には、改悪した MySQL サーバを作成しておけば、クライアントがテーブルに対してクエリを実行した時に、クライアント コンピュータ上に存在する全てのファイル (カレントユーザが読み取り権を持つ) を、LOAD DATA ステートメントの改悪した MySQL サーバが読み取れるということになります。

  • クライアントが Web サーバから接続する Web 環境では、ユーザは LOAD DATA LOCAL を使用して、Web サーバ プロセスが読み取りアクセス権を持つどのファイルでも読み取ることができます。これは、ユーザが SQL サーバに対してすべてのコマンドを実行できる場合です。この環境では、MySQL サーバに対するクライアントは実際には Web サーバであり、Web サーバに接続するユーザによるリモート プログラムのことではありません。

この問題を解決するには、MySQL 3.23.49 と MySQL 4.0.2 (Windows では 4.0.13 ) 以降の LOAD DATA LOCAL の扱い方を変更しました。

  • デフォルトで、MySQL クライアントとバイナリ配布のすべてを、--enable-local-infile オプションでコンパイルしました。これは MySQL 3.23.48 以前の MySQL との互換性のためです。

  • MySQL をソースから組み、--enable-local-infile オプションで configure を呼び出していない場合、mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) を明示的に呼び出すと指さなければ、クライアントは LOAD DATA LOCAL を使用できません。 項23.2.3.49. 「mysql_options() を参照のこと。

  • --local-infile=0 オプションで mysqld を起動すると、サーバ側からすべての LOAD DATA LOCAL コマンドを無効にできます。

  • mysql のコマンドライン クライアントでは、--local-infile[=1] オプションを指定すると、LOAD DATA LOCAL を有効化し、--local-infile=0 オプションで無効化します。同様に、mysqlimport では、--local または -L のオプションで、ローカルのデータ ファイル ロードを有効にします。どのような場合でも、ローカルでのロード操作は、サーバがそれを許可するかどうかによります。

  • オプション ファイルから [client] グループを読むような、Perl スクリプトまたはその他のプログラムで、LOAD DATA LOCAL を使用する場合、local-infile=1 をそのグループに追加できます。しかし、local-infile を認識しないプログラムで問題が発生しないようにするために、例示のように、loose- プレフィックスを使います。

    [client]
    loose-local-infile=1
    
  • LOAD DATA LOCAL INFILE を有効にする場合、サーバまたはクライアントのどちらかで、そのようなステートメントを発行しようとするクライアントは、次のようなエラー メッセージを受け取ります。

    ERROR 1148: The used command is not allowed with this MySQL version
    

MySQL Enterprise MySQL Network Monitoring and Advisory Service では、サーバを --local-infile オプションを有効にして起動する場合のセキュリティに関するアドバイスを提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

4.6.5. ユーザによる MySQL の実行

Windows 環境では、通常のユーザ アカウントで、Windows サービスとしてサーバを実行できます。

Unix 環境では、MySQL サーバの mysqld をどのユーザでも起動できます。しかし、セキュリティ面への配慮から、Unix root ユーザでサーバを実行することは推奨していません。mysqld を変更し、普通の権限なし Unix ユーザ、user_name で実行するには、次のことを行ないます。

  1. サーバ実行中であれば、終了する。(mysqladmin shutdown コマンドを使用)

  2. user_name でファイルへの読み書き込み権限がを与えるために、データベース ディレクトリとファイルを変更する。場合によっては、この作業を、Unix root ユーザで行なう必要がある。

    shell> chown -R user_name /path/to/mysql/datadir
    

    この作業を行なわない場合、user_name. で実行するときに、サーバからデータベースまたはテーブルへのアクセスができない。

    MySQL データ ディレクトリ内のディレクトリまたはファイルがシンボリック リンクである場合は、そのリンクに従い、ディレクトリとファイルを指しているところを変更する。場合によって、chown -R では、シンボリック リンクできないことがある。

  3. user_name というユーザでサーバを起動する。MySQL 3.22 以降を使用している場合は、別の方法として、Unix rootmysqld を起動し、--user=user_name オプションを使用する。mysqld が起動したら、接続を開始する前に、Unix ユーザの user_name に切り替えて、実行する。

  4. システムの起動時に自動的に任意のユーザでサーバを起動するには、user オプションを /etc/my.cnf オプション ファイルの [mysqld] グループに追加するか、サーバのデータ ディレクトリの my.cnf オプション ファイルを使用して、ユーザ名を指定する。

    [mysqld]
    user=user_name
    

Unix マシン自体が安全ではない場合、権限テーブルの MySQL root アカウントにパスワードを割り当てる。これをしないと、そのマシンのログイン アカウントを持つユーザであれば誰でも、 --user=rootmysql を実行でき、どのような操作をも行なうことができる。つまり、常に MySQL アカウントにパスワードを割り当てることが賢明である。そのサーバ ホストで別のログイン アカウントが存在する場合は特にそうである。項2.10. 「インストール後の設定とテスト」 を参照のこと。

4.7. MySQL アクセス権限システム

MySQL では、高度化し、かつ非標準のセキュリティおよび権限システムを採用しています。ここでは、それらがどのように動作するかを説明します。

4.7.1. 権限システムの役割

MySQL 権限システムの主な役割は、ホストから接続するユーザの認証と、SELECTINSERTUPDATEDELETE などのデータベースにおける権限があるユーザを関連付けることです。

アノニマス ユーザ (不特定多数のユーザー) を持つこと、そして、管理操作や LOAD DATA INFILE などのMySQL 特有の関数での権限を与えるといった追加の機能性を備えています。

4.7.2. 権限システムの機能

MySQL 権限システムでは、すべてのユーザが許可がある操作だけを行います。ユーザは MySQL サーバに接続すると、 接続元のホスト指定するユーザ名 でそのアイデンティティ (ID) を認識します。接続後のリクエスト発行では、権限システムが、ユーザ ID と それが行なう操作に応じて権限を設定します。

MySQL では、ホスト名とユーザ名を使用してユーザを認証します。1 つのユーザ名がインターネット上のどこででも同じユーザを示しているという保証がないためです。たとえば、 office.example.com から接続したユーザ joe は、home.example.com から接続した joe と同一人物とは限りません。 MySQL では、同じユーザ名でも異なるホストから接続するユーザ間で区別して、これを処理します。office.example.com から接続したjoe と、home.example.com から接続した joe には別々の権限セットを設定します。

MySQL のアクセス制御には、サーバに接続するクライアント プログラムを実行するときに、 2 段階を踏みます。

  • 段階 1:ユーザに接続する権限があるかどうかサーバがチェックする。

  • 段階 2:接続できた場合、要求ごとにそれを実行できる権限があるかどうかサーバがチェックする。たとえば、データベースのテーブルからレコードを SELECT したり、データベースのテーブルを DROP しようとすると、ユーザにそのテーブルの SELECT 権限があるかどうか、あるいはデータベースの DROP 権限があるかどうかをサーバがチェックする。

接続中に権限を変更した場合(ユーザ自身または第三者によって)、必ずしもその変更は次のクエリに反映するとは限りません。詳細は、項4.7.7. 「権限の変更が反映するタイミング」 を参照してください。

サーバは、mysql データベース (mysql と名付けられたデータベース) の権限テーブルに権限情報を保管します。MySQL サーバは、起動するとこのテーブルの内容をメモリに読み込み、項4.7.7. 「権限の変更が反映するタイミング」 で示すような状況においては、それらを再読み込みします。アクセス制御の決定は、権限テーブルの内部コピーを基に行います。

通常、GRANTREVOKE などのクエリを使用して、権限テーブルの内容を間接的に操作し、アカウントのセットアップや権限のコントロールを行ないます。項12.5.1. 「アカウント管理ステートメント」 も参照してください。ここでは、権限テーブルの根本的なストラクチャと、サーバがクライアントとのやりとりでどのようにそれを使用するかについて説明します。

サーバでは、両方の段階でのアクセス制御で、mysql データベースの userdb、 そして host テーブルを使用します。userdb のフィールドをここで示します。host テーブルは、db テーブルと類似しますが、項4.7.6. 「アクセス制御の段階 2: 接続確認」 で説明するように特別な使い方をします。

テーブル名userdb
スコープ フィールドHostHost
?UserDb
?PasswordUser
権限 フィールドSelect_privSelect_priv
?Insert_privInsert_priv
?Update_privUpdate_priv
?Delete_privDelete_priv
?Index_privIndex_priv
?Alter_privAlter_priv
?Create_privCreate_priv
?Drop_privDrop_priv
?Grant_privGrant_priv
?Create_view_privCreate_view_priv
?Show_view_privShow_view_priv
?Create_routine_privCreate_routine_priv
?Alter_routine_privAlter_routine_priv
?Execute_privExecute_priv
?Trigger_privTrigger_priv
?Event_privEvent_priv
?Create_tmp_table_privCreate_tmp_table_priv
?Lock_tables_privLock_tables_priv
?References_privReferences_priv
?Reload_priv?
?Shutdown_priv?
?Process_priv?
?File_priv?
?Show_db_priv?
?Super_priv?
?Repl_slave_priv?
?Repl_client_priv?
セキュリティ フィールドssl_type?
?ssl_cipher?
?x509_issuer?
?x509_subject?
リソース制御フィールドmax_questions?
?max_updates?
?max_connections?
?max_user_connections?

Event_privTrigger_priv のフィールドは MySQL 5.1.6 で追加しました。

アクセス制御の 2 段階目 (要求確認) で、要求がテーブルに関連する場合、サーバはそれぞれのクライアントに適切な権限があるかどうかを確認します。それに加えて、userdbhost の権限テーブルで、サーバが tables_privcolumns_priv テーブルを参照します。tables_privcolumns_priv テーブルで、テーブルとカラムの適切な権限制御を行なうことができます。これには次のフィールドがあります。

テーブル名tables_privcolumns_priv
スコープ フィールドHostHost
?DbDb
?UserUser
?Table_nameTable_name
??Column_name
権限フィールドTable_privColumn_priv
?Column_priv?
その他のフィールドTimestampTimestamp
?Grantor?

TimestampGrantor のフィールドは現在未使用です。.

ストアド ルーチンに関わる要求確認では、サーバは procs_priv テーブルを参照します。このテーブルには次のようなフィールドがあります。

テーブル名procs_priv
スコープ フィールドHost
?Db
?User
?Routine_name
?Routine_type
権限フィールドProc_priv
その他のフィールドTimestamp
?Grantor

Routine_type は、'FUNCTION' または 'PROCEDURE' の値を伴う ENUM フィールドであり、その行が示すルーチンのタイプを指します。このフィールドでは、関数とプロシージャが同じ名前である場合に、別々に権限を与えます。

TimestampGrantor のフィールドは現在未使用です。.

それぞれの権限テーブルには、スコープ フィールドと権限フィールドがあります。

  • スコープ フィールドは、テーブルの各登録 (エントリ) の範囲を特定します。たとえば、HostUser の値が 'thomas.loc.gov' および 'bob' である user テーブル エントリは、thomas.loc.gov ホストからサーバに接続しようとする bob を認証します。同様に、HostUserDb のそれぞれのフィールドの値が 'thomas.loc.gov''bob' 'reports' である db テーブル エントリは、thomas.loc.gov ホストから reports データベースに接続しようとする bob を認証します。tables_priv テーブルおよび columns_priv テーブルには、それぞれのエントリを許可しているテーブルまたはテーブルとカラムの組み合わせを示すスコープフィールドがあります。 procs_priv スコープ フィールドはエントリに適用するストアド ルーチンを示します。

  • 権限フィールドは、テーブル内のエントリごとに設定している権限、つまり何の操作を実行できるかを示します。サーバはさまざまな権限テーブルの情報を組み合わせて、ユーザの権限についての完全な記述を生成します。 この動作に適用できるルールについては 項4.7.6. 「アクセス制御の段階 2: 接続確認」 を参照してください。

スコープフィールドは文字列です。ここで示すように、それぞれのデフォルト値は空文字列です。

フィールド名
HostCHAR(60)
UserCHAR(16)
PasswordCHAR(16)
DbCHAR(64)
Table_nameCHAR(64)
Column_nameCHAR(64)
Routine_nameCHAR(64)

アクセスをチェックでは、Host 値の比較には大文字と小文字を区別します。UserPasswordDb、および Table_name の値については大文字と小文字を区別します。Column_nameRoutine_name の値は、大文字と小文字の区別は不要です。

userdbhost のテーブルでは、それぞれの権限を別々のカラムにリストしています。これは、ENUM('N','Y') DEFAULT 'N' と宣言しています。つまり、それぞれの権限は無効化、および有効化が可能です。

tables_privcolumns_privprocs_priv のテーブルでは、権限フィールドは SET フィールドとして宣言しています。これらのフィールド値はテーブルでコントロールしている権限の組み合わせを含みます。

テーブル名フィールド名設定可能な要素
tables_privTable_priv'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter', 'Create View', 'Show view', 'Trigger'
tables_privColumn_priv'Select', 'Insert', 'Update', 'References'
columns_privColumn_priv'Select', 'Insert', 'Update', 'References'
procs_privProc_priv'Execute', 'Alter Routine', 'Grant'

ここで、サーバが権限テーブルをどのように使用するかを簡潔に説明します。

  • user テーブルのスコープ フィールドで、着信した接続を許可または拒否のどちらかを決定する。接続を許可すると、user テーブルに設定している権限はいずれも、そのユーザのグローバル(スーパーユーザ)権限になる。 これらの権限は、サーバのすべてのデータベースに適用となる。

    ノート:グローバル権限はいずれも、すべてのデータベースに対する権限として扱うため、グローバル権限を持つユーザは、SHOW DATABASES を使用したり、 あるいは INFORMATION_SCHEMASCHEMATA テーブルを調べたりすると、すべてのデータベース名を閲覧できるようになる。

  • db テーブルのスコープ フィールドで、どのユーザがどのホストからどのデータベースにアクセスできるかを決定する。権限フィールドから、何の操作を許可しているか判断する。 データベースのレベルで権限があると、データベースとそのすべてのテーブルにアクセスできる。

  • host テーブルを、任意の db テーブル エントリをいくつかのホストに適用する場合、db テーブルで補完するものとして使用する。たとえば、1 人のユーザに対して、ネットワーク内の複数のホストからデータベースへアクセスすることを許可する場合、ユーザの db テーブル エントリの Host 値を空白のままにして、それらのホストのそれぞれのエントリを host テーブルに入力する。このメカニズムの詳細については、項4.7.6. 「アクセス制御の段階 2: 接続確認」 を参照のこと。

    ノートhost テーブルは、INSERTUPDATEDELETE などのステートメントで直接、変更する必要がある。GRANTREVOKE などのステートメントは、間接的に権限テーブルを修正し、これらのステートメントからは効果がない。MySQL のインストールでは、このテーブルは、例外を除き、使用しない。

  • tables_privcolumns_priv のテーブルは、 db テーブルと類似するが、これらはより詳細な設定が可能。データベース レベルではなく、テーブルおよびカラム レベルでの適用となる。テーブルで権限を与えた場合、それはテーブル、およびすべてのカラムでの適用となる。カラム レベルで権限を与えた場合、特定のカラムにだけの適用となる。

  • procs_priv テーブルはストアド ルーチンへの適用となる。ルーチン レベルで権限を与えた場合、単一のルーチンにだけの適用となる。

注意: 管理者権限 (RRELOADSHUTDOWN など)は、user テーブルで指定します。管理操作はデータベース固有ではなく、サーバそのもので行う操作です。そのため、この権限を他の権限テーブルで設定する必要はありません。実際に、管理操作を実行できるかどうか決定するときには、user テーブルを参照するだけで済みます。

FILE 権限は user テーブルで指定します。 これは管理者権限ではありません。サーバ ホスト上でのファイルの読み書きは、アクセスしているデータベースからは独立しています。

mysqld サーバは権限テーブルの内容を、起動時に 1 回メモリへ読み取ります。FLUSH PRIVILEGES ステートメントを発行するか、または mysqladmin flush-privileges あるいは mysqladmin reload のコマンドを実行して、このテーブルの再読み込みを行なうことも可能です。権限テーブルへの変更してから反映できるまでの詳細は 項4.7.7. 「権限の変更が反映するタイミング」 を参照してください。

権限テーブルの内容を変更するときは、その変更で、目的とする権限を適切に設定したかどうを確認してください。任意のアカウントへの権限をチェックするには、SHOW GRANTS ステートメントを使用します。(項12.5.4.16. 「SHOW GRANTS 構文」 を参照のこと。) たとえば、Hostpc84.example.com で、Userbob のアカウントに与えた権限を確認するには、次のようにステートメントを発行します。

SHOW GRANTS FOR 'bob'@'pc84.example.com';

権限関連問題の追加的な診断ヘルプに関しては、項4.7.8. 「Access denied エラーの原因」 を参照してください。その他、セキュリティに関連のアドバイスに関しては、項4.6. 「セキュリティ問題」 を参照してください。

4.7.3. MySQL 提供の権限

ユーザ権限に関する情報は、mysql データベース(mysql という名前のデータベース)の userdbhosttables_privcolumns_privprocs_priv などのテーブルにあります。MySQL サーバは起動時、および 項4.7.7. 「権限の変更が反映するタイミング」 で説明する状況下において、これらのテーブルの内容をメモリへ読み取ります。アクセス制御に関する決定は、権限テーブルの内部メモリを基に行ないます。

GRANTREVOKE などのステートメントで権限を指すときに使用する名前を、次の一覧に表示します。この一覧には、権限テーブルのそれぞれの権限に関連するカラム名とその権限を適用する内容 (適用範囲) も示します。それぞれの権限に関する意味などに関しては、項12.5.1.3. 「GRANT 構文」 を参照してください。

権限カラム適用範囲
CREATECreate_privデータベース、テーブル、またはインデックス
DROPDrop_privデータベースまたはテーブル
GRANT OPTIONGrant_privデータベース、テーブル、またはストアド ルーチン
REFERENCESReferences_privデータベースまたはテーブル
EVENTEvent_privデータベース
ALTERAlter_privテーブル
DELETEDelete_privテーブル
INDEXIndex_privテーブル
INSERTInsert_privテーブル
SELECTSelect_privテーブル
UPDATEUpdate_privテーブル
TRIGGERTrigger_privテーブル
CREATE VIEWCreate_view_privビュー
SHOW VIEWShow_view_privビュー
ALTER ROUTINEAlter_routine_privストアド ルーチン
CREATE ROUTINECreate_routine_privストアド ルーチン
EXECUTEExecute_privストアド ルーチン
FILEFile_privサーバ上のファイル アクセス
CREATE TEMPORARY TABLESCreate_tmp_table_privサーバ管理
LOCK TABLESLock_tables_privサーバ管理
CREATE USERCreate_user_privサーバ管理
PROCESSProcess_privサーバ管理
RELOADReload_privサーバ管理
REPLICATION CLIENTRepl_client_privサーバ管理
REPLICATION SLAVERepl_slave_privサーバ管理
SHOW DATABASESShow_db_privサーバ管理
SHUTDOWNShutdown_privサーバ管理
SUPERSuper_privサーバ管理

MySQL のリリースによっては、権限テーブルのストラクチャへの変更に、新たな権限または特徴を追加することになっています。新しいバージョンの MySQL にアップデートするときは、常に、権限テーブルの更新も同時に行い、カレント ストラクチャであることを確認し、新しい機能の利点を扱えるようにします。項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照してください。

EVENT および TRIGGER の権限は MySQL 5.1.6 に追加しました。

バイナリ ログを有効にした場合に格納関数の作成または置換するには、SUPER 権限が必要な場合があります。項17.4. 「ストアドルーチンとトリガのバイナリログ」 を参照してください。

CREATEDROP などの権限で、新たなデータベースやテーブルの作成が行なえます。既存のデータベースやテーブルを削除することも可能です。MySQL 5.1.10 初期では、ALTER TABLE ... DROP PARTITION のステートメントを分割したテーブルに使用するときに DROP 権限を必要としています。MySQL 5.1.16 初期では、DROP 権限は TRUNCATE TABLE に使用します。(TRUNCATE TABLE には DELETE 権限が必要。) ユーザに対して、mysql データベース のDROP 権限を与えると、そのユーザで MySQL のアクセス権限があるデータベースの削除が行なえます。

SELECTINSERTUPDATEDELETE などは、データベースの既存テーブルのレコード操作ができるようにする権限です。ANALYZE TABLEOPTIMIZE TABLEREPAIR TABLE などのテーブル保守に関するステートメントには、INSERT 権限が必要です。

SELECT ステートメントで、テーブルから直接にレコードを読み取る場合には SELECT 権限が必要です。SELECT ステートメントはテーブルへのアクセスはできませんが、データベースへのアクセス権がなくても実行できます。たとえば、mysql クライアントをシンプルな計算機として使用するような場合です。

SELECT 1+1;
SELECT PI()*2;

INDEX は、インデックスを作成または破棄(削除)できる権限です。INDEX 権限は既存テーブルにでの適用となります。テーブルに対して CREATE 権限がある場合、CREATE TABLE ステートメントにインデックス定義を含めることも可能です。

ALTER 権限があると、ALTER TABLE でテーブルのストラクチャを変更したり、テーブルの名前を変更することができます。

CREATE ROUTINE はストアド ルーチンの作成に必要な権限です。ALTER ROUTINE はストアド ルーチンの置換や削除に必要な関数です。EXECUTE はストアド ルーチンの実行に必要な権限です。

TRIGGER はテーブルのトリガの作成と削除に必要な権限です。MySQL 5.1.6 以前では、この操作には、SUPER 権限が必要です。

EVENT はイベント スケジューラのイベント セットアップに必要な権限です。

GRANT はユーザが自分の権限を他のユーザに与える権限です。これはデータベース、テーブル、ストアド ルーチンに使用できます。

FILE は、LOAD DATA INFILE および SELECT ... INTO OUTFILE ステートメントを使用してサーバ上でファイルの読み書きを行う権限です。FILE 権限を持つユーザは、サーバ ホストのすべてのファイル、つまり MySQL サーバの読み込み可能ファイルを読み込めます。(これは、この権限を持つユーザであれば、サーバがファイルへのアクセスを許可するために、データベース ディレクトリのファイルを読むことができるということです。) さらに、FILE 権限があるユーザは、MySQL サーバが書き込みアクセスのあるディレクトリに、新しいファイルを作成できます。セキュリティ対策として、サーバは既存ファイルの上書きは行ないません。

その他の権限は、管理者用の権限です。この多くは、mysqladmin プログラムや SQL ステートメントを発行して実行できます。次の一覧テーブルは、どの管理権限で、mysqladmin コマンドで実行できるかを示します。

権限実行可能なコマンド
RELOADflush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh, reload
SHUTDOWNshutdown
PROCESSprocesslist
SUPERkill

reload コマンドは、権限テーブルを再読み込みするよう、サーバに命令します。refresh コマンドは、すべてのテーブルをフラッシュし、ログファイルを開いて閉じます。flush-privileges は reload のシノニムです。他の flush-xxx コマンドも refresh と同様の役割を果たしますが、範囲が限られているため、状況によって使い分けます。たとえば、ログ ファイルだけをフラッシュするときは、refresh の代わりに flush-logs を使用します。

shutdown コマンドでサーバをシャットダウンします。これに関連する SQL ステートメントはありません。

processlist コマンドは、サーバで実行中のスレッドに関する情報を表示します。kill コマンドはサーバ スレッドを強制終了します。ユーザはいつでも自分のスレッドを表示および強制終了することができますが、他のユーザで開始したスレッドを表示するには PROCESS 権限が必要です。強制終了するには SUPER 権限が必要です。項12.5.5.3. 「KILL 構文」 を参照してください。

CREATE TEMPORARY TABLESCREATE TABLE ステートメントの TEMPORARY のキーワード使用を可能にする権限です。

LOCK TABLES は、SELECT 権限でテーブルをロックするために、明示的な LOCK TABLES の使用を許可する権限。この権限で書き込みロックを制御して、不正読み込みからテーブルを守ります。

REPLICATION CLIENT は、SHOW MASTER STATUS および SHOW SLAVE STATUS の使用を可能にする権限です。

REPLICATION SLAVE は、スレーブ サーバがマスタとしてカレント サーバに接続するときに使用するアカウントに対して与える権限です。この権限がないと、スレーブは、マスタ サーバのデータベースに対して行なわれた更新を要求できません。

SHOW DATABASES はデータベース名の閲覧を可能にする権限です。SHOW DATABASE 権限がないアカウントでは、限定範囲でデータベースの内容を閲覧することができます。--skip-show-database オプションでサーバを起動している場合には、このステートメントを使用できません。ノート: グローバル権限があると、データベースに対するすべての権限 があることを意味します。

必要がない限り、この権限をアカウントに与えないでください。FILE 権限の付与と管理権限に関しては、次の事柄に対する十分な注意が必要です。

  • FILE 権限の悪用で、MySQL サーバの読み取り可能ファイル、またはカレント データベース ディレクトリのファイルをデータベース テーブルに対して、SELECT を使用してその内容にアクセス可能になる。

  • GRANT 権限は、ユーザが自分の権限を他のユーザに与えることができる。2 人のユーザが異なる権限を持ち、両方とも GRANT 権限がある場合、お互いの権限を組み合わせることができる。

  • ALTER 権限は、テーブルの名前を変更して、権限システムを崩壊することができる。

  • SHUTDOWN権限の悪用で、サーバがシステム終了し、他のユーザへのサービス妨害となる。

  • PROCESS 権限は、パスワードの設定や変更を行うクエリなどを含め、現在実行中のクエリの平文テキストを表示することができる。

  • SUPER 権限は、クライアントの終了と、サーバ動作方法を変更できる。

  • mysql データベースに対する権限があれば、パスワードおよびその他のアクセス権限情報を変更することができる。(パスワードを暗号化で保護しているため、悪意のあるユーザが単に読み取ってもテキスト形式のパスワードを知ることはできない)。user テーブルの Password カラムにアクセスできれば、それを悪用して特定ユーザの MySQL サーバにログインできる。(必要権限があれば、そのユーザはパスワードを書き換えることもできる)。

    MySQL Enterprise 必要以上のグローバル権限を付与すると、セキュリティ リスクに繋がります。MySQL Network Monitoring and Advisory Service では、該当するアカウントに関する警告を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

次に、MySQL の権限システムでは不可能なことを示します。

  • 特定のユーザに対してアクセス拒否を明示的に指定することはできない。つまり、特定のユーザを明確に割り出し、そこからの接続を拒否することができない、という意味。

  • データベース内のテーブルの作成および破棄の権限をユーザに与え、それと同時にデータベースの作成および破棄をできないようには指定できない。

  • アカウントのパスワードはグローバルで適用する。つまり、データベース、テーブル、ルーチンなど特定のオブジェクトに対するパスワードは付けられない。

4.7.4. MySQL サーバへの接続

MySQL クライアント プログラムでは、通常、MySQL サーバにアクセスするときに、接続先のホスト、ユーザ名、パスワードといった接続パラメータを指定する必要があります。

  • MySQL サーバを実行しているホスト名

  • ユーザ名

  • パスワード

mysql クライアントで次で示すように、コマンドライン プロンプト (ここでは shell> ) で起動する場合

shell> mysql -h host_name -u user_name -pyour_pass

-h-u-p オプションの別の形は、--host=host_name--user=user_name--password=your_pass です。-p または --password= に後続するパスワードの間には、スペースを入れません

-p または --password オプションを使用するけれども、パスワード値を指定しない場合、クライアント プログラムがパスワード入力を指示します。このパスワードは入力しても表示しません。このやり方は、パスワードをコマンドラインで与えるよりは安全です。システムを使用するユーザによっては、ps auxw などのコマンドを実行して、コマンドラインで指定するパスワードを見る可能性があります。項4.8.6. 「パスワードのセキュリティ」 を参照してください。

MySQL クライアント プログラムでは、指定のない限り、接続パラメータにデフォルト値を使用します。

  • 初期設定時のホスト名は localhost

  • デフォルトのユーザ名は Windows では ODBC 、Unix では、Unix のログイン名。

  • -p または --password を指定しなければ、パスワード無しになる。

したがって、Unix ユーザ joe では、以下のコマンドがいずれも同じ意味になります。

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

他の MySQL クライアントでも同様です。

Unix システムでは、接続時に別のデフォルト値を使用するように設定することができます。これにより、クライアント プログラムを起動するたびにコマンドラインで指定する必要がなくなります。設定方法は 2 つあります。

  • ホームディレクトリ内にある .my.cnf 設定ファイルの [client] セクションで接続パラメータを指定する。このセクションは次のようになる。

    [client]
    host=host_name
    user=user_name
    password=your_pass
    

    項3.3.2. 「オプションファイルの使用」でオプション ファイルの詳細を記述しています。

  • 環境変数を使用して接続パラメータを指定する。mysql のホストは、MYSQL_HOST で指定できる。MySQL ユーザ名は、USER を使用して指定できる(Windows と NetWare のみ)。パスワードは、MYSQL_PWD を使用して指定できる。(ただし、これは安全ではない。項4.8.6. 「パスワードのセキュリティ」 を参照のこと)。変数の一覧は 項2.14. 「環境変数」 を参照してください。

4.7.5. アクセス制御の段階 1: 接続確認

ユーザが MySQL サーバに接続しようとした場合、そのユーザ ID、およびそれを正しいパスワードで裏付けできるかどうかによって、サーバは接続の許可または拒否を行います。パスワードが正しくない場合、サーバはアクセスを完全に拒否します。正しければ、サーバは接続を許可し、段階 2 に進んで要求を待ちます。

ユーザ ID は、2 つの情報に基づきます。

  • 接続元のホスト

  • MySQL ユーザ名

ID チェックには、user テーブルの 3 つのスコープフィールド(HostUserPassword)を使用します。user テーブルエントリが、指定した HostUser と一致し、入力したパスワードが正しい場合のみ、接続許可になります。

user テーブルの Host値 (スコープ フィールド) には次の方法で値を指定できます。

  • Host 値にはホスト名または IP アドレスを使用できる。ローカルホストを指定する場合は 'localhost' を使用する。

  • ワイルドカード文字 ‘%’ および ‘_’ を Host フィールドに使用できる。LIKE 演算子で実行するマッチング操作と同様の効果がある。たとえば、Host 値としての '%' はすべてのホスト名を意味する。これに対して、'%.mysql.com' という値は mysql.com ドメインのすべてのホスト名と一致する。

    MySQL ネットワーク%’ のような広宿主の指示子はセキュリティ リスクをもたらします。 MySQL Network Monitoring and Advisory Service ではこのような脆弱性に対応するセーフガードを提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

  • IP アドレスとして指定する Host 値に、ネットワークアドレスを示すためのネットマスクを使用できます。次はその例です。

    GRANT ALL PRIVILEGES ON db.* TO david@'192.58.197.0/255.255.255.0';
    

    これは、davidclient_ip という IP アドレスのクライアント ホストから接続できます。これには次の条件があります。

    client_ip & netmask = host_ip
    

    つまり、GRANT ステートメント表示です。

    client_ip & 255.255.255.0 = 192.58.197.0
    

    この条件に該当し、MySQL サーバに接続できる IP アドレスは、192.58.197.0 から 192.58.197.255 までの範囲のもということになります。

    ノート:ネットマスクの使用は 8、16、24、または 32 ビットのいずれかのアドレスを使用するようにサーバへ知らせます。たとえば、次の通りです。

    • 192.0.0.0/255.0.0.0: 192 クラスの A ネットワークのすべて

    • 192.168.0.0/255.255.0.0: 192.168 クラスの B ネットワークのすべて

    • 192.168.1.0/255.255.255.0: 192.168 1 クラスの C ネットワークのすべて

    • 192.168.1.1: 特定の IP のみ。

    次に示すネットマスク (28 ビット) は使用できません。

    192.168.0.1/255.255.255.240
    
  • db テーブル行 (エントリ) の 空白の Host

    は、その権限が、クライアントのホスト名と一致する host テーブルの行のものと組み合わさるという意味です。この権限は、OR (ユニオン) ではなく、AND (インターセクション) 操作を使用して組み合わせられています。 host テーブルの使用については、項4.7.6. 「アクセス制御の段階 2: 接続確認」 を参照してください。

    別の権限テーブルの空白の Host 値は、'%' と同じである。

たとえば、'144.155.166.%' がサブネットのすべてのホストと一致する、というように、Host カラムの IP ワイルドカードの値を使用できるということは、ホストを 144.155.166.somewhere.com と命名するなどして、誰かがこの機能 (セキュリティー上の弱点) を悪用できるということです。これを阻止するために、MySQL では、数字やドットで始まるホスト名との一致しないようになっています。つまり、1.2.foo.com のようなホスト名の場合、この名前は、権限テーブルの Host カラムとは一致しないということです。IP ワイルドカード値は、IP アドレスとだけ一致し、ホスト名とは一致しません。

User フィールドには、ワイルドカード文字は使用できません。空白の値は使用でき、これは任意のユーザ名と一致します。user テーブル エントリに空白のユーザ名があり、接続で空白ユーザーにマッチする場合、そのユーザはクライアントが実際に指定した名前のユーザではなく、匿名ユーザ(名前なしのユーザ)との解釈になります。この場合、接続中(段階 2 の間)のフル アクセス チェックをすべて、空白のユーザ名で行うということです。

Password フィールドは空白にできます。これはどのパスワードにも一致するという意味ではなく、そのユーザがパスワードを指定せずに接続する必要があるという意味です。

user テーブルの空白ではない Password 値は、暗号化パスワードを表します。 MySQL では、パスワードを平文テキストでは保存しません。接続しようとするユーザが入力したパスワードを暗号化します(PASSWORD() 関数を使用)。クライアントおよびサーバがパスワードの確認を行うときは、その暗号化パスワードを使用します。(このとき、その接続を経由して、暗号化パスワードを転送することはありません)。注意: MySQL から見ると暗号化パスワードが実際のパスワードであるため、暗号化パスワードにだれにもアクセスできないようにしてください。特に、一般のユーザに mysql データベース内のテーブルの読み取りアクセス権を与えないでください。

MySQL 5.1 では (最初の実装は MySQL 4.1 から)、MySQL は従来とは異なるパスワードおよびログインメカニズムを採用しています。万が一、TCP/IP パケットの傍受や mysql データベースのキャプチャが行なわれた場合でも安全確保できるようになっています。パスワードの暗号化に関する詳細は 項4.7.9. 「MySQL 4.1 のパスワードハッシュ」 を参照してください。

次の一覧は、user テーブルエントリの Host 値および User 値のさまざまな組み合わせがどのように着信の接続に適用するかを示します。

Host User 正当な接続
'thomas.loc.gov''fred'thomas.loc.gov から接続する fred
'thomas.loc.gov'''thomas.loc.gov から接続するすべてのユーザ
'%''fred'任意のホストから接続するfred
'%'''任意のホストから接続するすべてのユーザ
'%.loc.gov''fred'loc.govドメイン内の任意のホストから接続する fred
'x.y.%''fred'x.y.netx.y.comx.y.edu などから接続する fred (実用的ではない)
'144.155.166.177''fred'IP アドレス 144.155.166.177 のホストから接続する fred
'144.155.166.%''fred'144.155.166 クラス C サブネットの任意のホストから接続する fred
'144.155.166.0/255.255.255.0''fred'1 つ上の例と同じ

クライアントのホスト名と着信するユーザ名が、user テーブルのエントリ一つ以上と、一致する可能性があります。前述の例で説明すると、たとえば、thomas.loc.gov からの fred の接続は、前述の一覧のいくつかのエントリと一致します。

複数のエントリが一致した場合、サーバは該当するものを選択するために、次のことを行ないます。

  • サーバが user テーブルをメモリに読み込むときに、エントリのソートをする。

  • クライアントが接続しようとすると、サーバはソート順でエントリを照会する。

  • サーバはクライアントのホスト名とユーザ名が一致する最初のエントリを使用する。

user テーブルが次の内容であると仮定して、これがどのように作用するかを説明します。

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

サーバがテーブルをメモリに読み込むと、最も具体的な Host 値を最初にもってきます。ここでは、Host カラムの '%' は 「任意のホスト」 を意味し、具体性が最も低いものとなります。同じ Host 値のエントリ間で、最も具体的な User 値を最初にもってきます。ここでは、空白の User 値は 「任意のユーザ」 を意味し、具体性が最も低いものとなります。ソートした user テーブルは次のようになります。

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

クライアント接続が試みられると、サーバはソートしたエントリで突き合わせ (マッチング) を行い、最初に一致したものを使用します。localhost からの jeffrey による接続では、2 つのエントリが一致します (空白ユーザ名のエントリが接続ホスト名とユーザ名の両方で一致) 。HostUser のカラム値をみると、'localhost''' の値が一致します。 そして、'%''jeffrey' の値が一致します。ここで、ソートしたときに、'localhost' が最も具体的な値であるため、これが最初に来ます。よってサーバは、表示の順序で選択します。

次に、別例を示します。user テーブルが次の内容である場合

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

ソート後のテーブルは次のようになります。

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

thomas.loc.gov からの jeffrey による接続は、最初のエントリを一致とし、whitehouse.gov からの jeffrey による接続は 2 番目のエントリとなります。

サーバが接続の突き合わせを行うとき、ユーザ名とは、明示的にそのユーザを名付けている (ユーザであると定義している) すべてのエントリが最初に来ると、考えることができますが、これは間違っています。上記の例でもわかるように、thomas.loc.gov からの jeffrey による接続は、'jeffrey'User フィールド値であるエントリではなく、ユーザ名なしのエントリと最初に一致します。つまり、jeffrey で接続する、とユーザ名を指定したにもかわらず、彼は匿名ユーザとして認証されています。

接続したが、権限が予期したものと違うという場合、別のユーザで認証している可能性があります。サーバがどのユーザで認識が行なわれたかを突き止めるには、CURRENT_USER() 関数を (項11.10.3. 「情報関数」 参照) 使用します。(その接続に実際に一致しているユーザとホストの組み合わせを確認できます。) そのときに、 user_name@host_name という形の値を返します。これは、UserHost のカラムの値が、user テーブル行でどのように一致となっているのかを示します。たとえば、jeffrey で接続して、次のようなクエリを発行したとします。

mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost     |
+----------------+

ここでの結果は、user テーブル行で一致したものが、空白の User であることを示します。つまり、サーバは jeffrey を匿名ユーザとして扱っています。

このような認証に関わる診断をする、別の方法として、user テーブルを出力して、それをマニュアル (手動) でソートし、最初の組み合わせをどのような経緯でしたか調べます。

4.7.6. アクセス制御の段階 2: 接続確認

接続を確立すると、サーバは段階 2 に移行します。その接続での要求ごとに、サーバはユーザに実行できる権限があるかどうかを、操作タイプに基づいてチェックします。ここで、権限テーブルの権限フィールドが関係してきます。権限は、userdbhosttables_privcolumns_privprocs_priv のテーブルで設定できます。各権限テーブルのフィールドのリストについては、項4.7.2. 「権限システムの機能」 を参照してください。

user テーブルは、デフォルト (カレント) データベースに関係なく、ユーザに対してグローバル権限を設定します。たとえば、user テーブルに DELETE 権限があるユーザは、そのサーバ ホストのどのデータベースのレコードでも削除できます。つまり、user テーブルに対する権限はスーパーユーザ権限ということです。そのため、user テーブルで権限を設定になる対象は、サーバ管理者やデータベース管理者などのスーパーユーザだけにしておくのが賢明です。他のユーザについては、user テーブルの権限を 'N' に設定しておき、権限の付与は適切なレベルで行なうこととしてください。権限の付与には、データベース、テーブル、カラム、ルーチンなど、データベース依存で設定してください。

db テーブルおよび host テーブルでは、データベース依存の権限を設定します。 スコープ フィールドには次の方法で値を指定します。

  • ワイルドカード文字の ‘%’ および ‘_’ を、両テーブルの Host フィールドと Db フィールドで使用できる。これには、LIKE 演算子で実行するマッチングと同様の意味があります。権限付与に、どちらかの文字を使用するときに、それをバックスラッシュでエスケープします。たとえば、‘_’ 文字 (アンダーライン) をデータベース名の一部として使用するには、GRANT コマンドでそれを ★‘\_’★ として指定する。

  • db テーブルの 「'%' Host」 値は、「任意のホスト」 を意味する。db テーブルの空白の Host 値は、「hostテーブルを参照すること'」 を意味する。(このセクションでプロセスについて後述)

  • host テーブルの '%' または空白の Host 値は、「任意のホスト」 を意味する。

  • 両テーブルにおいて host テーブルの '%' または空白の Db 値は、任意のデータベース」 を意味する。

  • 両テーブルにおいて空白の User 値は、匿名ユーザを意味する。

db テーブルと host のテーブルは、サーバ起動時に読み取りとソートを行ないます (user テーブル読み込みと同時)。db テーブルは HostDbUser のそれぞれのスコープ フィールドでソートし、host テーブルは Host と Db のスコープ フィールドでソートします。user テーブルでは、最も具体的な値が最初に、最も抽象的な値が最後の順でソートし、サーバによるエントリの突き合わせでは、最初に一致したエントリを使用します。

tables_privcolumns_privprocs_privのテーブルではそれぞれ、テーブル依存およびカラム依存の権限を設定します。スコープ フィールドには次の方法で値を指定します。

  • ワイルドカード文字の ‘%’ および ‘_’ を両テーブルの Host フィールドで使用できる。これらには、LIKE 演算子で実行するマッチングと同義です。

  • 両テーブルにおいて '%' または空白の Host 値は、「任意のホスト」 を意味する。

  • 両テーブルの DbTable_nameColumn_name のそれぞれのフィールドで、ワイルドカードおよび空白は使用できない。

tables_privcolumns_privprocs_priv などのテーブルは、HostDbUser のフィールドでソートが行なわれます。これは db テーブルのソートと同様ですが、ワイルドカードの使用が Host フィールドだけの限定になるため、よりシンプルです。

サーバは、受け取る要求の妥当性をソートしたテーブルで確認します。SHUTDOWN または RELOAD などの管理側の権限が必要な要求では、サーバは user テーブル エントリをチェックします。これは、このテーブルが唯一、管理権限の指定を行なうテーブルであるためです。要求操作を許可していれば、アクセスを認め、そうでない場合は拒否します。たとえば、mysqladmin shutdown コマンドを実行するときに、user テーブル エントリで SHUTDOWN 権限の設定がなければ、db テーブルや host テーブルをチェックすることなくアクセスを拒否します。これらのテーブルには Shutdown_priv カラムが存在しないため、チェックしません)。

INSERTUPDATE などデータベース関連の要求では、サーバは最初に、user テーブル エントリでユーザのグローバル(スーパーユーザ)権限をチェックします。ここで、要求の操作が許可があれば、アクセスを認めます。user テーブルのグローバル権限が十分ではない場合には、サーバはユーザのデータベースに関する権限を db テーブルおよび host テーブルでチェックします。

  1. サーバは、db

  2. テーブルの HostDbUser のそれぞれのフィールドをチェックする。Host フィールドと User フィールドでは、接続ユーザのホスト名と MySQL ユーザ名がチェックの対象になる。Db フィールドでは、ユーザがアクセスしようとしているデータベースをチェックする。Host および User に該当するエントリがない場合には、アクセスを拒否する。

  3. db テーブル エントリが一致し、その Host フィールドが空白ではない場合、そのエントリがユーザのデータベース依存の権限を定義する。

  4. 一致している db テーブル エントリの Host フィールドが空白の場合、これは host テーブルが、データベースにアクセスできるホストを指定することを意味する。このとき、host テーブルの Host フィールドと Db フィールドがチェックの対象になる。host テーブル内に一致するエントリがない場合は、アクセスを拒否する。一致するエントリがあれば、ユーザのデータベースに対する権限が、db および host テーブル エントリを、和集合ではなく、共通集合として計算する。つまり、両方のエントリの 'Y' が権限であることを指す。このように、db テーブル エントリで全般的な権限を設定し、host テーブル エントリでホストごとに権限を制限することができる。

サーバは、db および host テーブルエントリからデータベースに対する権限の特定が済むと、それらの権限を user テーブルのグローバル権限と足し合わせます。その結果が要求の操作を許可するものであれば、アクセスを認めます。そうでない場合、サーバは tables_privcolumns_priv のテーブルでユーザのテーブル権限とカラム権限をチェックし、これらのテーブルに対するユーザの権限を追加します。その結果に基づき、アクセスの許可または拒否を行ないます。ストアド ルーチンの操作には、サーバは tables_privcolumns_priv ではなく、procs_priv に重点を置きます。

ブール値で表すと、上記のユーザ権限算出法は次のような総括になります。

global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges
OR routine privileges

user 内のグローバル権限が十分ではない場合に、サーバがその十分ではないグローバル権限を、データベース、テーブル、およびカラム権限と足し合わせることは不可解です。しかし、これには、要求に複数の権限が必要な場合があるという事情があります。たとえば、INSERT INTO ... SELECT ステートメントを実行するには、INSERT 権限および SELECT 権限の両方が必要になります。この権限のうち 1 つの権限が user テーブル内のエントリにあり、もう 1 つの権限が db テーブル内のエントリにあるという場合には、要求を実行するために必要な権限をユーザを持っているにも関わらず、サーバがどちらか一方のテーブルだけでは判断できないため、両テーブルのエントリにある権限を組み合わせた結果で、許可/拒否の判断を行ないます。

GRANT または REVOKE などのステートメントは、host テーブルには影響しません。そのため、MySQL インストレーションではあまり、このステートメントを使用することはありません。直接に変更しなければならない場合、たとえば、セキュリティで保護したサーバ リストの保守などを行なうときなど、稀に使用します。その例として、TcX (TcX DataKonsult AB) で、host テーブルには、ローカル ネットワークのすべてのマシンをリストしていて、すべての権限をここで設定しています。

host テーブルを使用して、セキュリティ保護のない ホストを示すこともできます。 セキュリティ保護のない公開エリア内に、コンピュータ public.your.domain があるとします。ここで、次のように、host テーブルのエントリを使用して、ネットワーク内のそのコンピュータ以外のホストすべてへのアクセスを許可することができます。

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (all privileges set to 'N')
| %.your.domain      | %  | ... (all privileges set to 'Y')
+--------------------+----+-

ノート: 常に、権限テーブルをテストして(SHOW GRANTSなどを使用)、アクセス権限を目的どおりに設定していることを確認してください。

4.7.7. 権限の変更が反映するタイミング

mysqld を起動すると、メモリにすべての権限テーブルが読み込まれます。この時点で、内部メモリのテーブルがアクセス制御の効力を施行します。

サーバが権限テーブルをリロードするときは、既存のクライアント接続の権限は次のように発効します。

  • テーブルとカラムの権限での変更はクライアントが次に要求を行なうときに発効する。

  • データベースの権限での変更は、次の USE db_name ステートメントを発行するときに発効する。

    ノート:クライアント アプリケーションは、データベース名をキャッシュしていることがあるため、実際に別のデータベースを変更するか、FLUSH PRIVILEGES ステートメント を実行しないと、権限効力を発揮できない可能性がある。

  • グローバル権限とパスワードでの変更は、次にクライアントが接続するときに発効する。

GRANT, REVOKE, or SET PASSWORD などのステートメントを使用して、間接的に権限テーブルを変更する場合は、サーバがこれらの変更を認識し、その変更があった直後に権限テーブルをメモリへリロードします。

INSERTUPDATEDELETE などのステートメントを使用して、直接に権限テーブルを変更する場合は、サーバを再起動するか、またはテーブルのリロードを行なうまでその権限チェックは施行しません。手動で権限テーブルをリロードするには、FLUSH PRIVILEGES ステートメントを発行するか、mysqladmin flush-privileges または mysqladmin reload コマンドを実行します。

権限テーブルを直接変更したけれど、リロードを忘れたという場合、単に、サーバを再起動するまで、その効果は発揮しません。変更したにも関わらず、その効果がないようなときは、再起動することをお勧めします。

4.7.8. Access denied エラーの原因

ここでは、MySQL サーバに接続しようとして Access denied エラーが発生した場合の対処法について説明します。

  • まず、サーバが起動していることを確認します。起動していなければ接続はできません。たとえば、サーバに接続しようとして、次のようなメッセージが出るときには、サーバが立ち上がっていない可能性があります。

    shell> mysql
    ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
    shell> mysql
    ERROR 2002: Can't connect to local MySQL server through socket
    '/tmp/mysql.sock' (111)
    

    サーバは起動しているが、TCP/IP ポート、名前付きパイプ、Unix ソケット ファイルで接続しようとしている場合に、サーバが使用しているものが異なる場合があります。これを修正するには、クライアント プログラムを呼び出すときに、--port オプションを適切なポート番号を指すように指定します。または --socket で適切な名前付きパイプまたは Unix ソケット ファイルを指定します。ソケット ファイルの場所を検索するには、次のコマンドを使用します。

    shell> netstat -ln | grep mysql
    
  • サーバがアクセス制御に使用する権限テーブルは正確にセットアップする必要があります。Windows のバイナリ配布、または Linux の RPM 配布など、配布の種類よっては、インストールのプロセスで、権限テーブルがある mysql データベースを初期化します。これをしない種類の配布では、手動で権限テーブルを初期化する必要があります。これには、mysql_install_db スクリプトを実行します。詳細は 項2.10.2. 「Unix のインストール後のプロシージャ」 を参照してください。

    権限テーブルを初期化する必要があるかどうかを調べるには、データ ディレクトリの mysql をチェックします。通常、データ ディレクトリは、data または var と名前で、MySQL をインストールしたディレクトリ下にあります。mysql データベース ディレクトリに user.MYD ファイルがあることを確認してください。これをしない場合は、mysql_install_db スクリプトを実行してください。このスクリプトを実行してから、サーバを起動し、次のコマンドを実行して、イニシャル権限をテストします。

    shell> mysql -u root test
    

    これで、エラーなしでサーバに接続できます。

  • 問題なくインストールできたら、サーバに接続して、ユーザとアクセス制限についてセットアップします。

    shell> mysql -u root mysql
    

    MySQL root には最初からパスワードがありません。そのため、サーバへの接続は問題なくできます。これには、セキュリティ面でのリスクが伴うため、root アカウントのパスワードは、MySQL アカウントをセットアップするときに、セットすることをお勧めします。初期パスワードの設定手順に関しては、項2.10.3. 「最初の MySQL アカウントの確保」 を参照してください。

    MySQL ネットワーク MySQL Network Monitoring and Advisory Service では、セキュリティ関連の最適化を励行しています。購読者には、パスワードなしのユーザを検出すると、それを警告しています。詳細は、http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

  • MySQL のバージョンを更新するときには、mysql_upgrade スクリプトを実行する必要があります。新バージョンの機能によっては、権限テーブルのストラクチャを変更することがあります。そのため、アップグレードした後は、常に、テーブルがカレント ストラクチャであるかどうかを確かめてください。この手順に関しては 項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照してください。

  • クライアント プログラムで接続時に次のようなエラー メッセージが出る場合、そのクライアントが生成する形式よりも新しい形式でのパスワードをサーバが必要としている、ということを示します。

    shell> mysql
    Client does not support authentication protocol requested
    by server; consider upgrading MySQL client
    

    これに関する対処法に関しては、項4.7.9. 「MySQL 4.1 のパスワードハッシュ」 および 項B.1.2.3. 「Client does not support authentication protocol を参照してください。

  • root で接続をしようとする場合に、次のようなエラーが出るときには、'root'User フィールドに、user テーブルのエントリがないことを示します。そのため、mysqld がクライアントのホスト名を識別できない状態です。

    Access denied for user ''@'unknown' to database mysql
    

    この場合、--skip-grant-tables オプションでサーバを立ち上げ、/etc/hosts ファイル、または \windows\hosts で、ホストのエントリを付加します。

  • クライアント プログラムは、環境変数またはオプション ファイルで指定する接続パラメータを使用します。そのため、コマンドラインからデフォルトの接続パラメータを指定していない場合には、適切ではないパラメータを送ることがあります。そのときは、環境変数、および該当するオプション ファイルを調べます。たとえば、オプションなしでクライアントを実行するときに、Access denied となる場合、オプション ファイルのどこかで古いパスワードを指定している可能性があります。

    使用しているオプション ファイルをクライアント プログラムで抑制することができます。これには、 --no-defaultsを行使します。

    shell> mysqladmin --no-defaults -u root version
    

    クライアントが使用するこのオプション ファイルの一覧は、項3.3.2. 「オプションファイルの使用」 を参照してください。環境変数の一覧は、項2.14. 「環境変数」 を参照してください。

  • 次のエラーが出る場合は、 使用している root のパスワードが誤っていることを示します。

    shell> mysqladmin -u root -pxxxx ver
    Access denied for user 'root'@'localhost' (using password: YES)
    

    パスワードを指定していない場合に、このようなエラーが出るときには、オプション ファイルのどこかに誤ったパスワードがあることを示します。前述の項目で説明したように、--no-defaults で確かめてください。

    パスワードの変更に関する情報は、項4.8.5. 「パスワードの設定」 を参照してください。

    root パスワードを忘れた場合、--skip-grant-tablesmysqld を再起動して、パスワードを変更します。詳細は 項B.1.4.1. 「How to Reset the Root Password」 を参照してください。

  • パスワードの変更に、SET PASSWORDINSERTUPDATE を使用する場合は、PASSWORD() 関数でそのパスワードを暗号化します。これらのステートメントを使用するときに、PASSWORD() 関数を使用しないと、パスワードは機能しません。たとえば、次にようなすテーとメントでパスワードをセットしても、それを暗号化していない場合、そのユーザはそれ以降の接続ができません。

    SET PASSWORD FOR 'abe'@'host_name' = 'eagle';
    

    そのため、パスワードを次のようにセットします。

    SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');
    

    GRANT または CREATE USER ステートメント、あるいは mysqladmin password コマンドでパスワードを指定するときは、PASSWORD() 関数は不要です。これらの方法では、自動的に、PASSWORD() をパスワードの暗号化に適用します。詳細は 項4.8.5. 「パスワードの設定」 および 項12.5.1.1. 「CREATE USER 構文」 を参照してください。

  • localhost はローカル ホスト名のシノニムです。ホストを明示的に指定しないときには、これがクライアント接続でのデフォルトのホストとなります。

    このような問題を回避するには、--host=127.0.0.1 オプションをサーバ ホストを明示的に指名します。その場合、TCP/IP で、ローカルの mysqld サーバに接続します。TCP/IP 接続には、--host オプションで実際のローカル ホストのホスト名を使用できます。この場合、そのサーバの同じホストでクライアント プログラムを実行している場合でも、ホスト名をサーバホストの user テーブル エントリで指定する必要があります。

  • mysql -u user_name でデータベースに接続しようとするときに、Access denied エラーが出る場合は、user テーブルに問題がある可能性があります。これをチェックするには、mysql -u root mysql の実行し、次の SQL ステートメントを発行します。

    SELECT * FROM user;
    

    結果には、コンピュータのホスト名と MySQL ユーザ名と一致する HostUser のカラムのエントリが出ます。

  • Access denied というエラー メッセージは、ログインしようとしているユーザ名、接続元のホスト、およびパスワードを使用したかどうかを通知します。通常、userテーブルに、ホスト名とユーザ名に完全にマッチするエントリが 1 つあり、これが  このエラーメッセージに出ます。たとえば、エラーメッセージに using password: NO と出る場合、パスワードなしでログインしようとしたことを示します。

  • MySQL サーバを実行しているホストではないホストから接続しようとして以下のエラーが発生する場合、クライアント ホストと一致する Host 値では、レコードが user テーブルにないということを示します。

    Host ... is not allowed to connect to this MySQL server
    

    これは、接続時に使用するクライアント ホスト名とユーザ名を組み合わせたアカウントをセットアップすることで解決します。

    接続元のコンピュータの IP アドレスまたはホスト名がわからない場合、user テーブルの Host カラムに '%' を使用します。そして、そのクライアント コンピュータから接続しようとするときに、SELECT USER() クエリを使用して、実際にどのように接続したか確認します。そのときに、user テーブル エントリの '%' をログにある実際のホスト名と置き換えます。この作業を行なわない場合、どのホストからでもそのユーザ名での接続ができることになるので、セキュリティ上の問題になります。

    Linux 上で、このエラーが発生する別の理由として、使用しているバイナリ MySQL バージョンが、glibc ライブラリが異なるバージョンを使用してコンパイルしている可能性があります。この場合、OS または glibc をアップグレードするか、または MySQL のソース配布をダウンロードして (自分で) コンパイルします。ソース RPM は通常、コンパイルおよびインストールが簡単です。そのため、これは大した問題ではありません。

  • ホスト名で接続しようとしたにもかかわらず、エラーメッセージにホスト名がない、またはホスト名が IP アドレスである場合は、MySQL サーバで、 クライアント ホストの IP アドレスを解決しようとしてエラーになったことを示します。

    shell> mysqladmin -u root -pxxxx -h some_hostname ver
    Access denied for user 'root'@'' (using password: YES)
    

    これは、DNS に問題があることを示します。これを修正するには、mysqladmin flush-hosts を実行して、内部 DNS ホスト名キャッシュをリセットします。項6.5.6. 「MySQLの DNS の使用」 を参照してください。

    この解決策としては、次のことを検討します。

    • DNS サーバの問題を割り出し、それを修正する。

    • ホスト名ではなく、IP アドレスを MySQL の権限テーブルで指定する。

    • /etc/hosts または \windows\hosts にクライアントのマシン名のエントリを入力する。

    • mysqld--skip-name-resolve オプションで起動する。

    • mysqld--skip-host-cache で起動する。

    • Unix では、サーバとクライアントを同じマシンで実行している場合、localhost に接続する。localhost への Unix 接続は、TCP/IP ではなく Unix ソケット ファイルを使用する。

    • Windows では、サーバとクライアントを同じマシンで実行して、サーバが名前付きパイプ接続をサポートしている場合、ホスト名 . (ピリオド) に接続する。. (ピリオド) への接続には、TCP/IP ではなく、名前付きパイプを使用する。

  • mysql -u root test は機能するけれども、your_hostname がローカル ホストの実際のホスト名であるにも関わらず、mysql -h your_hostname -u root testAccess denied が出る場合、user テーブルにホストへの正確な名前がない可能性があります。この場合によくある問題として、user テーブル エントリの Host 値が適切ではないホスト名を指定して、システムでの名前解決ルーチンが完全に適切であるドメイン名を返すことがあります (またはこの逆の場合もあります)。たとえば、ホストを 'tcx' とするエントリが user テーブルにあるにも関わらず、DNS で MySQL にホスト名は 'tcx.subnet.se' であると伝えてしまうと、そのエントリが適用になりません。そのため、user テーブルに、ホストの IP アドレスを Host のカラム値として付加します。または、user テーブルに、'tcx.%' というように、ワイルドカード文字を Host 値に使用します。しかし、‘%’ をホスト名の終わりに付けるのは、セキュリティ面での安全を確保できない という理由から 推奨はしていません

  • mysql -u user_name test は機能するけれども、mysql -u user_name other_db_name が機能しない場合、そのユーザには、 other_db_name のデータベース アクセスを許可していないことを意味します。

  • mysql -u user_name はサーバ ホストで実行したときには機能するけれども、mysql -h host_name -u user_name がリモートのクライアント ホストから実行したときに機能しない場合、リモート ホストからはそのユーザ名でサーバにアクセスできないようになっていることを意味します。

  • Access denied エラーの原因がわからない場合、user テーブルのエントリから、‘%’ または ‘_’ などのワイルドカード文字が付いている Host 値をすべて削除します。ここで、Host = '%' および User = 'some_user' という新しいエントリを挿入して、これで同じマシンから接続するために localhost を指定することができるようになると考えることは誤りです。これは機能しません。その理由は、デフォルト権限で、Host = 'localhost' および User = '' というエントリを含むためです。このエントリには、Host カラムに 'localhost' という '%' よりも明確な値があるため、localhost から接続するときに新しいエントリよりもデフォルトのエントリが優先になります。そのため、正確な手順としては、Host = 'localhost' および User = 'some_user' と改めて指定するか、または Host = 'localhost' および User = '' のエントリを削除します。このエントリを削除したら、 FLUSH PRIVILEGES ステートメントを発行して、権限テーブルのリロードを必ず行なってください。

  • 次のようなエラーが出る場合、db または host のいずれかのテーブルで問題がある可能性があります。

    Access to database denied
    

    db テーブルで選択するエントリに空白の Host カラムがある場合、db テーブルのエントリで適用するホストを指定するときに、対応するエントリが host テーブルに、 1 つ以上あることを確認してください。

  • MySQL サーバに接続はできるけれども、SELECT ... INTO OUTFILE または LOAD DATA INFILE を発行すると、Access denied が出る場合は、user テーブルのエントリで、FILE 権限がないことを意味します。

  • INSERT, UPDATE または DELETE などのステートメントを使用して、直接に権限テーブルを変更するときに、それが効力を発揮していない場合は、FLUSH PRIVILEGES ステートメント、または mysqladmin flush-privileges コマンドを実行して、サーバへのその権限テーブルの再読み込みを行ないます。これをしないと、変更した内容が次にサーバを起動するまで発効しません。UPDATE コマンドで root パスワードを変更した場合は、その権限をフラッシュするまで、新たなパスワードを使用する必要はありません。その時点 (変更しただけ) では、サーバがまだパスワードを変更したことを認識していません。

  • セッション中に権限が変更された可能性がある場合、MySQL の管理者がそれを変更した可能性があります。権限テーブルのリロードは、それ以降のクライアント接続に影響します。これは、既存の接続に対しても影響します。これに関しては、項4.7.7. 「権限の変更が反映するタイミング」 を参照してください。

  • Perl、PHP、Python、ODBC プログラムでアクセスに問題がある場合は、mysql -u user_name db_name または mysql -u user_name -pyour_pass db_name で、サーバへの接続を試行します。 mysql クライアントを使用して接続できる場合は、問題の根源は、アクセス権限ではなく、プログラムにあります。-p とパスワードの間には、空白はありませんが、 --password=your_pass シンタックスを使用して、パスワードを指定することもできます。パスワードなしで -p --password オプションを使用すると、MySQL でパスワードの入力を指示します。

  • テストするときは、mysqld サーバを --skip-grant-tables オプションで起動します。そのとき、MySQL 権限テーブルを変更でき、mysqlaccess スクリプトを使用して、変更内容に目的の効力があるかどうかをチェックできます。その内容が意図していたものである場合、mysqladmin flush-privileges を実行して、mysqld サーバに新たな権限テーブルを使用するよう指示できます。権限テーブルのリロードは、--skip-grant-tables オプションを上書きします。そのため、この上書きでサーバにリロードした権限テーブルをサーバのシステム終了や再起動をしなくても使い始めることができます。

  • 前述の事柄を試しても、解決しない場合、--debug=d,general,query などの mysqld サーバをデバッグ オプションで立ち上げます。つまり、接続試行に関するホストとユーザの情報と、使用したコマンドも関する情報を出力します。Creating Trace Files を参照してください。

  • MySQL 権限テーブルについて、ここで示したこと以外の問題がある場合は、メーリング リストで問題提起してください。そのときには、MySQL 権限テーブルのダンプも添付してください。テーブルのダンプは、mysqldump mysql コマンドでします。バグのレポートは、項1.7. 「質問またはバグの報告」 の手順に従ってください。場合によっては、mysqldump を実行するためには、--skip-grant-tables オプションで、mysqld を再起動する必要があります。

4.7.9. MySQL 4.1 のパスワードハッシュ

MySQL ユーザ アカウントは、mysql データベースの user テーブルでリストしています。それぞれの MySQL アカウントにはパスワードを割り当てますが、user テーブルの Password カラムで保存になるのは、平文テキストのパスワードではなく、パスワードで計算したハッシュ値です。パスワード ハッシュ値は、PASSWORD() 関数で計算しています。

MySQL は、クライアントとサーバ間通信の 2 つのフェーズでパスワードを使用します。

  • フェース 1 : クライアントがサーバに接続しようとするとき、初期認証ステップとして、クライアントがパスワードを提示する。このパスワードは、クライアントが使用するアカウントの user テーブルで保存するハッシュ値と一致している必要がある。

  • フェーズ 2: クライアントは接続した後、クライアントで、user テーブルにあるパスワード ハッシュを設定または変更することができる(適切な権限がある場合)。これには、クライアントが、PASSWORD() 関数を使用してパスワード ハッシュを生成するか、GRANT または SET PASSWORD ステートメントを使用する。

つまり、クライアントが最初の接続を試行するとき、サーバが認証にハッシュ値を使用します。接続したクライアントが PASSWORD() 関数を呼び出したり、GRANT または SET PASSWORD ステートメントを使用してパスワードの設定または変更を行うと、サーバがハッシュ値を生成 します。

セキュリティ面での向上と、パスワード盗難の危険性に対応する パスワード ハッシュ メカニズムを MySQL 4.1 で更新しました。しかし、この新しいメカニズムはサーバとクライアント同士が相互に MySQL 4.1 以上での使用を必要とするため、それ以外のバージョンを使用している場合には、互換性に問題があります。つまり、MySQL 4.1以上のクライアントは、パスワード ハッシュの新旧メカニズムの両方を理解するため、MySQL 4.1 より前のサーバにも接続できます。MySQL 4.1 より前のクライアントで MySQL 4.1 以上の サーバに接続する場合、問題が発生する可能性があります。たとえば、MySQL 3.23 の mysql のクライアントが 5.1 サーバに接続を試行すると、次のようなエラー メッセージ表示を伴う問題があります。

shell> mysql -h localhost -u root
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

別の例として、 MySQL 4.1 以上にアップグレードしてから、古いバージョンの PHP で mysql 拡張モジュールを使用するときにも、このような問題が発生します。( 項23.3.1. 「MySQLとPHPに対する共通問題」 を参照のこと。)

次に、新旧のパスワード メカニズムでの違いと、MySQL 4.1 前の古いクライアントとの下位互換性の維持を必要とする場合のアップグレードについて説明します。項B.1.2.3. 「Client does not support authentication protocol で、追加情報の参照もしてください。ここでの内容は、PHP で MySQL データベースを 4.0 以前から 4.1 以上にする場合に特に重要です。

注意:ここでの内容は、MySQL 4.1 を境とする動作について説明しています。ここで、4.1 の動作として説明している内容は、実際には 4.1.1 で導入しています。MySQL 4.1.0 は 「特異的なリリース」 が行なわれたため、4.1.1 以降に実装したメカニズムとは若干異なります。4.1.0 以降のバージョン間での違いに関する詳細は、MySQL 5.0 Reference Manual を参照してください。

MySQL 4.1 より前のバージョンでは、PASSWORD() 関数で計算するパスワード ハッシュは 16 バイト長です。次にその例を示します。

mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e   |
+--------------------+

MySQL 4.1 より前のバージョンでは、user テーブルの Password カラム(ハッシュを保存する場所)も 16 バイト長です。

MySQL 4.1 からは、PASSWORD() 関数で、それまでより長い、41 バイトのハッシュ値を生成します。

mysql> SELECT PASSWORD('mypass');
+-------------------------------------------+
| PASSWORD('mypass')                        |
+-------------------------------------------+
| *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
+-------------------------------------------+

それに伴い、このバイト幅に合わせて、user テーブルの Password カラムも 41 バイト幅です。

  • MySQL 5.1 の新規インストールで、Password カラムは自動的に 41 バイト幅になる。

  • MySQL 4.1 (4.1.1 を含む 4.1 シリーズ) から MySQL 5.1 へのアップグレードでは、パスワード ハッシュ メカニズムが同一であるため、このアップグレードでは、ここに挙げるパスワード ハッシュに関する問題は発生しません。これ以外のアップグレード、たとえば、MySQL 4.1 よりも古いバージョンから 5.1 にする場合は、まず、MySQL 4.1 へアップグレードしてから、 5.1 へのアップグレード (インルトール) を行ないます。

拡張後の Password カラムには、新旧どちらの形式でもパスワード ハッシュを保存できます。パスワード ハッシュ値の形式を次の 2 つの基準で判断します。

  • バイト幅 (文字列の長さが16 バイトまたは41 バイトのどちらか)。

  • パスワード ハッシュの開始文字。新しい形式のパスワードは ‘*’ 文字で始まる。旧形式のパスワードはこれ以外の文字で始まる。

パスワードハッシュ形式は、長い方が暗号化に優れ、クライアント認証においても、旧形式の短いハッシュよりもセキュリティ面での安全性が高まります。

パスワードハッシュのバイト幅の違いは、サーバでのパスワード認証方法と、接続クライアントのパスワード変更に対するサーバでのパスワード ハッシュの生成方法に影響します。

サーバでのパスワード認証方法では、Password カラムの幅で、次のように影響します。

  • カラム幅が短いと、ハッシュ認証が短くなる。(制限への影響)

  • カラムが長いと、長短両方のハッシュを保てるため、サーバ認証では、次のどちらかの方法を使用する。

    • 4.1 より前でのクライアント接続は可能。しかし、旧ハッシュ メカニズムで理解するため、短いハッシュのアカウントだけを認証する。

    • 4.1 以降のクライアントは、長短どちらのハッシュのアカウントも認証する。

ハッシュのアカウントが短くでも、実際は認証プロセスが 4.1 以降のクライアントであれば、古いクライアントを使用しているよりは、セキュリティ面での安全を確保しています。認証のセキュリティは以下の順で高くなります。

  • 短いパスワード ハッシュでアカウントに対して、4.1 より前のバージョンのクライアント認証

  • 短いパスワード ハッシュでアカウントに対して、4.1 以降のクライアント認証

  • 長いパスワード ハッシュのアカウントに対して、 4.1 以降のクライアント認証

サーバが接続クライアントに対してパスワード ハッシュを生成する方法には、Password カラムの幅と --old-passwords オプションが影響を与えます。つまり、4.1 以降のサーバでは、Password カラムがハッシュ値 (長さ) に対応する、そして、--old-passwords オプションを指定していない、という条件を満たすと、長いハッシュを生成します。ここでは、次のことに注意します。

  • Password カラムが 41 バイト のハッシュを保存できる長さであること。4.1 へのアップグレード後に、mysql_fix_privilege_tables スクリプトを実行して、Password カラムが長くなったことを更新して知らせる。ここで、カラムの更新を行なわず、4.1 より前の長さの 16 バイトのままの状態にしておくと、クライアントが PASSWORD()GRANTSET PASSWORDを使用してパスワードの変更操作を行うときに、サーバはまだハッシュが長くなったことを知らされていないため、長いハッシュは収まらないと認識し、短いハッシュを生成する。

  • Password カラムの長さ (幅) が十分であれば、長短どちらのパスワードハッシュも保存できる。この場合、サーバを --old-passwords オプションで起動していないときは、PASSWORD()GRANTSET PASSWORD で、長いハッシュを生成する。このオプションを指定すると、強制的に短いパスワードハッシュを生成する。

--old-passwords オプションを使用する目的には、サーバが長いパスワード ハッシュを生成する環境において、4.1 より前のクライアントと下位互換性を保てるようにすることがあります。このオプションは認証に影響するのではなく、4.1 以降のクライアント、つまり新しいメカニズムのクライアントでは長いパスワード ハッシュのアカウントを使用できるようになっているため、それがパスワードの変更操作の結果として、サーバの user テーブルに、長いパスワード ハッシュを保存しないようにします。長いパスワード ハッシュを保存してしまうと、 4.1 より前のクライアントが、このアカウントを使用できなくなります。たとえば、--old-passwords オプションを指定しないで接続を行なうと、次に示すようなシナリオが想定できます。

  • 古いバージョンのクライアントが、短いパスワード ハッシュのアカウントで接続する。

  • このクライアントがアカウントのパスワードを変更する。--old-passwords オプションをかけていなければ、アカウントに長いパスワード ハッシュの生成が可能になる。

  • そして、古いバージョンのクライアントがアカウントに長いパスワード ハッシュをセットしていた場合、長いパスワードは新しいメカニズムでの認証を行なうため、このクライアントが改めて、その長いパスワードをセットしたアカウントからは接続ができなくなります。つまり、このアカウントに長いパスワード ハッシュがあることを、テーブルに読み込ませてしまうと、そのクライアントが古いバージョンであるために、長いハッシュを認識することができません。(4.1 以降の新しいバージョンのクライアントは長いパスワードを認識します。) 

このシナリオでは、4.1 より前のバージョンのクライアントをサポートする必要がある場合には、4.1 以降のサーバを稼動するのは危険であり、これを回避するには、--old-passwords オプションが必要であることを示しています。--old-passwords オプションでサーバを立ち上げていれば、パスワード変更の操作を行なっても、長いパスワード ハッシュを生成することはありません。これにより、古いバージョンのクライアントでアカウントにアクセスできなくなるということはありません。つまり、クライアントの不注意で、パスワード変更が長いパスワード ハッシュの生成を起因して、アクセスできなくなるということはありません。

--old-passwords オプションの短所は、どのようなパスワードを作成しても、短いハッシュになることです。これは 4.1 を使用しているクライアントにも該当します。そのため、長いパスワード ハッシュによるセキュリティのメリットを活用できません。4.1 を使用しているクライアントに、長いハッシュでアカウントを作成する必要がある場合などは、--old-passwords オプションを使用しないで、サーバが実行中のときに、その操作を行なう必要があります。

4.1 以降のサーバが実行中のときに考えられるケースとしては、次のようなシナリオがあります。

シナリオ 1: ユーザ テーブルの Password カラム値の幅が短い場合

  • Password カラムには、短いハッシュだけが保存の対象になる。

  • クライアント認証に、サーバが短いハッシュだけをし使用する。

  • 接続クライアントでは、PASSWORD()GRANTSET PASSWORD などを使用するパスワード ハッシュの生成操作では、完全に短いハッシュを使用する。アカウントのパスワードの変更で、長くで設定してもパスワード ハッシュは短くなる。

  • --old-passwords を使用するが、これには何の効果もない。その理由は、Password カラムが短いハッシュだけを受け入れるため、サーバは短いパスワード ハッシュだけを生成しているからである。

シナリオ 2: Password カラムに長いハッシュを保存できるが、サーバを --old-passwords オプションで起動しない場合

  • Password カラムには、長短、両方のハッシュが保存の対象になる。

  • 4.1 以降のクライアントは、長短どちらのハッシュのアカウントも認証する。

  • 4.1より前のクライアントでは、短いハッシュのアカウントだけを認証する。

  • 接続クライアントでは、PASSWORD()GRANTSET PASSWORD などを使用するパスワード ハッシュの生成操作では、完全に長いハッシュを使用する。アカウントのパスワードの変更で、長いパスワード ハッシュのアカウントになる。

前述したように、このシナリオでの問題点は、4.1 より前のクライアントが短いパスワード ハッシュのアカウントでアクセスができなくなることです。GRANT, PASSWORD(), or SET PASSWORD を使用して該当アカウントのパスワードを変更することは、そのアカウントに長いパスワード ハッシュを与えることになります。この時点から、4.1 より前のクライアントを、4.1 にアップグレードしなければ認証ができません。

この問題の対処するには、パスワードを特別の方法で変更します。たとえば、通常、アカウントのパスワード変更には、SET PASSWORD を次のように使用しています。

SET PASSWORD FOR 'some_user'@'some_host' = PASSWORD('mypass');

パスワードを変更するけれども短いハッシュで作成する場合には、OLD_PASSWORD() 関数を使用します。

SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('mypass');

OLD_PASSWORD() 関数は、明らかに短いハッシュを生成する必要があるような場合に使用します。

シナリオ 3: Password カラムに長いハッシュを保存できるが、サーバを --old-passwords オプションで 4.1 以降のサーバ起動する場合

  • Password カラムには、長短、両方のハッシュが保存の対象になる。

  • 4.1 以降のクライアントは、長短どちらのハッシュのアカウントも認証する。(注意:長いハッシュは、--old-passwords オプションを使用しないでサーバを起動したときにだけ作成できる。 )

  • 4.1より前のクライアントでは、短いハッシュのアカウントだけを認証する。

  • 接続クライアントでは、PASSWORD()GRANTSET PASSWORD などを使用するパスワード ハッシュの生成操作では、完全に短いハッシュを使用する。アカウントのパスワードの変更で、長くで設定してもパスワード ハッシュは短くなる。

このシナリオでは、--old-passwords オプションが長いハッシュの生成を抑制するため、長いパスワード ハッシュのアカウントを作成することはできません。さらに、--old-passwords オプションを使用する前に長いハッシュでアカウントを作成する場合、--old-passwords を行使中にアカウントのパスワードを変更すると、短いパスワードのアカウントになるため、長いハッシュのセキュリティ面でのメリットを活用できなくなります。

次に、これらのシナリオの問題を概括します。

シナリオ 1 では、セキュリティ上の安全をより確保できる長いハッシュの長所を活用できません。

シナリオ 2 では、OLD_PASSWORD() を明示的に使用しないで、パスワードを変更する場合、4.1 より前のバージョンのクライアントが短いハッシュのアカウントではアクセスできなくなる。

シナリオ 3 では、--old-passwords オプションが、短いハッシュのアカウントのアクセスを抑制していますが、パスワード変更操作が長いハッシュを短いハッシュに戻します (操作で長いハッシュに変更してもその操作が取り消しになる)。この短くなったハッシュは、--old-passwords を施行している間は、元 (長いハッシュ) に戻せません。

4.7.9.1. アプリケーション プログラムに対するパスワードハッシュ変更の影響

アプリケーション側でも、PASSWORD() を使用してパスワードを生成している場合、MySQL 4.1 にアップグレードすると、アプリケーションとの互換性に問題が生じます。本来、PASSWORD() は MySQL ユーザのパスワード管理専用であるため、アプリケーションではこの関数を実行すべきではありません。しかし現状では、いくつかのアプリケーション側でも、それぞれの目的で PASSWORD()を使用しています。

MySQL バージョンを 4.1 以降にアップグレードして、長いパスワード ハッシュが生成できる状態でサーバを実行すると、アプリケーションで PASSWORD() を使用している場合は、アプリケーションが壊れます。推奨の対処法として、アプリケーションを修正して SHA1() または MD5() など、別の関数を使用してハッシュ値を生成するように設定します。 この別の関数を使用することが不可能な場合は、OLD_PASSWORD() 関数を使用しますが、これは、旧形式の短いハッシュを生成するための関数です。(注意: OLD_PASSWORD() は将来サポートしなくなる可能性があります)。

短いハッシュを生成するような状況下でサーバを実行している場合には、 OLD_PASSWORD() を利用できますが、これは、PASSWORD() と同等です。

PHP ユーザは、使用している MySQL データベースをバージョン 4.0 以前から、バージョン 4.1 以降にするときには、項23.3. 「MySQL PHP API」 を一読してください。

4.8. MySQL ユーザ アカウント管理

このセクションでは、MySQL サーバのクライアントのアカウントのセットアップ方法を説明します。次の項目に関して説明します。

  • MySQL で使用するアカウント名とパスワードの定義と OS で使用している名前とパスワードとの違い

  • 新規アカウントの追加と既存アカウントの削除

  • パスワードの変更

  • パスワードの安全使用に関するガイドライン

  • SSL 接続の安全確保

4.8.1. MySQL ユーザ名とパスワード

MySQL アカウントをサーバ接続が可能なユーザからのユーザ名とクライアント ホスト、またはホスト、と定義します。アカウントにはパスワードがあります。MySQL で使用するユーザ名とパスワードは、オペレーティング システムで使用するものとは特徴的な違いがあります。

  • MySQL で認証目的に使用するユーザ名は、Windows や Unix などで使用しているユーザ名 (ログイン名) とは関係がありません。Unix の場合は、MySQL クライアントがデフォルトで、現在使用している Unix のユーザ名を MySQL のユーザ名としてログインを行なうことがありますが、これは利便性との兼ね合わせです。クライアント プログラムで -u または --user のオプションでユーザ名を指定することができるため、デフォルト値は簡単に書き換えることができます。しかし、これは、誰でも適当なユーザ名を使用してサーバ接続を試行できるという意味でもあるため、すべての MySQL アカウントにパスワードをつけることで、データベースの安全を確保します。つまり、パスワードなしのアカウントのユーザ名を指定できる者であれば、サーバへの接続に成功します。

  • MySQL ユーザ名には、最大 16 文字まで使用できます。これは、MySQL のサーバとクライアントでハードコード (決め打ち) しています。mysql データベースのテーブル定義を変更するなどして、この文字制限を回避しないでください

    注意mysql データベースのテーブルは、MySQL AB による指示がない限り、絶対に改造しないでください。(項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照のこと。) MySQL のシステム テーブルの再定義を試行すると、予期しない結果を招く恐れがあります。

    オペレーティング システムのユーザ名は、MySQL ユーザ名とは完全に無関係です。最大文字数も異なります。たとえば、 Unix ユーザ名の最大文字数は、8 文字です。

  • MySQL パスワードは、オペレーティング システムのログイン パスワードとは別物です。Windows や Unix のマシンにログインするパスワード、およびそのマシンにある MySQL サーバへのアクセスに使用するパスワードとは一切無関係です。

  • MySQL では、Unix ログインプロセスのアルゴリズムとは別のアルゴリズムで、パスワードを暗号化する。MySQL のパスワード暗号化には、PASSWORD() SQL 関数、Unix のパスワード暗号化には、ENCRYPT() SQL 関数です。 PASSWORD() 関数と ENCRYPT() 関数の詳細については、項11.10.2. 「暗号化関数と圧縮関数」 を参照してください。注意: バージョン 4.1 以降のMySQL は、接続時のパスワード保護に、より高度な認証方式を採用しています。これは、TCP/IP パケットの盗聴や、mysql データベースのキャプチャが行なわれた場合でも、セキュリティを保持できるようになっています。初期バージョンでは、パスワードは user テーブルに暗号化して保存していますが、暗号化パスワード値に関する知識は MySQL サーバ接続に通用します。

MySQL をインストールするとき用に、権限テーブルには初期設定のアカウント セットを投入しています。そのアカウントには名前とアクセス権限があります。パスワードの割り与て方法に関しては、項2.10.3. 「最初の MySQL アカウントの確保」 を参照してください。その後、セットアップを行い、GRANTREVOKE などのステートメントで MySQL アカウントの変更や削除などを行ないます。詳細は、項12.5.1. 「アカウント管理ステートメント」 を参照してください。

コマンドライン クライアントで MySQL サーバに接続するときは、ユーザ名とパスワードを使用するアカウントに指定します。

shell> mysql --user=monty --password=guess db_name

短文のオプションを使用すると、コマンドは次のようになります。

shell> mysql -u monty -pguess db_name

-p オプションと後続のパスワード値の間には、空白はありません。項4.7.4. 「MySQL サーバへの接続」 を参照してください。

前述のコマンドには、コマンドラインでパスワードを入れています。これは、セキュリティ面でのリスクを伴います。詳細は 項4.8.6. 「パスワードのセキュリティ」 を参照してください。この問題を解決するには、パスワード値を入れずに、--password または -p オプションを指定します。

shell> mysql --user=monty --password db_name
shell> mysql -u monty -p db_name

オプションにパスワード値がない場合、クライアント プログラムがプロンプトを出力し、パスワードの入力を待機します。ここの例示では、パスワード オプションに空白 (スペース) を入れて区切っているため、db_nameパスワードとは解釈しません

オペレーティング システムによっては、MySQL がパスワードを呼び出すときに使用するライブラリ ルーチンで、入力するパスワードは最大 8 文字であることを自動的に制限します。これは、システム ライブラリでの問題で、MySQL とは関係ありません。MySQL では内部的にパスワードの文字数を制限することはありません。この問題を回避するには、MySQL パスワードを変更しますが、そのときは、8 文字よりも少ない文字数にするか、またはオプション ファイルにパスワードを入力します。

4.8.2. MySQL への新規ユーザの追加

MySQL アカウント作成方法は、2 通りあります。

  • CREATE USER または GRANT などのステートメントをアカウント作成に使用する。

  • INSERTUPDATEDELETE などのステートメントで直接、MySQL の権限テーブルを操作する。

推奨方法は、CREATE USERGRANT などのアカウント作成のステートメントを使用する方法です。これは、的確であり、エラーを防ぎます。詳細は 項12.5.1.1. 「CREATE USER 構文」 および 項12.5.1.3. 「GRANT 構文」 を参照してください。

アカウント作成の別の方法としては、MySQL アカウント管理の機能を提供している、phpMyAdmin などのサード パーティ プログラムを使用することもできます。

次に、新規ユーザのセットアップする mysql クライアント プログラムの使用方法を例示します。この例示では、項2.10.3. 「最初の MySQL アカウントの確保」 で説明するように、デフォルト設定の権限でセットアップしています。これは、変更するには、MySQL root ユーザとして MySQL サーバに接続する必要があることを示します。この root アカウントには、mysql データベースの INSERT 権限と RELOAD 管理権限も必要です。

まず、mysql プログラムを使用してサーバに MySQL root ユーザとして接続します。

shell> mysql --user=root mysql

root アカウントにパスワードを割り当てた場合には、mysql コマンドで --password または -p のいずれかのオプションも使用します。

root でサーバに接続した後に、新規アカウントを追加します。次のステートメントでは、GRANT で新規アカウントを 4 つ追加しています。

mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'localhost'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost';
mysql> GRANT USAGE ON *.* TO 'dummy'@'localhost';

GRANT ステートメントで追加したアカウントは、次のような属性を持ちます。

  • monty というユーザ名と some_pass というパスワードのアカウントが 2つ存在します。どちらもフル権限を持つスーパーユーザのアカウントです。'monty'@'localhost') というアカウントは、ローカル ホストから接続するときにだけ使用できます。一方の 'monty'@'%' というアカウントは、どのホストからでも接続できます。注意: monty というアカウントは両方とも、monty としてどこからでも接続できる必要があります。この localhost でアカウントを持っていない場合、monty でローカル ホストから接続したときに、mysql_install_db で作成している localhost のエントリで、匿名ユーザのアカウントとして優先になります。つまり、 monty が匿名ユーザとして扱われます。この理由は、'monty'@'%' よりも、匿名ユーザの方が具体的な Host カラム値にあるため、匿名の方が、user テーブルのソート順で先にきます。. (user テーブルのソートに関しては、項4.7.5. 「アクセス制御の段階 1: 接続確認」 を参照してください。)

  • admin というユーザ名でパスワードがないアカウントがあります。このアカウントは、.ローカル ホストから接続するときにだけ使用できます。そして、RELOADPROCESS の管理権限があります。この権限は、 admin ユーザが、 to execute the mysqladmin reloadmysqladmin refreshmysqladmin flush-xxxmysqladmin processlist などのコマンドを実行できます。.データベースへのアクセスに関する権限はありません。必要に応じて、追加の GRANT ステートメントを発行して、そのような権限を後から追加することができます。

  • 4番目には、dummy というユーザ名でパスワードなしのアカウントがあります。このアカウントは、ローカル ホストから接続するときにだけ使用できます。権限は一切ありません。GRANT ステートメントで USAGE 権限を使用すると、全く権限のないアカウントを作成できます。これには、すべてのグローバル権限を 'N' でセッティングする効果があります。(ここでは、このアカウントには後から特定の権限を付与するものとしています。)

GRANT の択一的な方法として、INSERT ステートメントを発行して、FLUSH PRIVILEGES でサーバに権限テーブルをリロードさせるという方法で、直接に、前述と同じ内容のアカウントを作成することができます。

shell> mysql --user=root mysql
mysql> INSERT INTO user
    ->     VALUES('localhost','monty',PASSWORD('some_pass'),
    ->     'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user
    ->     VALUES('%','monty',PASSWORD('some_pass'),
    ->     'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user SET Host='localhost',User='admin',
    ->     Reload_priv='Y', Process_priv='Y';
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('localhost','dummy','');
mysql> FLUSH PRIVILEGES;

INSERT でアカウントを作成するときに、FLUSH PRIVILEGES を使用する理由には、その権限テーブルの再読み込みをサーバに行なわせるという目的があります。これをしないと、サーバを再起動するまで、変更内容が反映しません。GRANT でアカウントを作成するときは、FLUSH PRIVILEGES は不要です。

INSERT を伴う PASSWORD() 関数を使用する理由には、パスワードの暗号化という目的があります。GRANT ステートメントはパスワードの暗号化を自動的に行なうため、PASSWORD() は不要になります。

'Y' はアカウントに対する権限を有効にします。MySQL のバージョンによっては、INSERT ステートメントの最初の 2 つのエントリで、'Y' の数が異なる場合があります。admin アカウントでは、SET を使用した読み込みやすい拡張 INSERT シンタックスを採用する場合もあります。

dummy アカウントの INSERT ステートメントには、user テーブルのエントリの HostUserPassword のコラムだけに対して、値を割り当てています。どの権限も具体的にはセットしていません。そのため、MySQL がデフォルト値として、'N' を割り当てています。これは、GRANT USAGE で行なうこと同じものです。

ノート: スーパーユーザのアカウントをセットアップするには、'Y' にセットした権限コラムで、user テーブル エントリを作成します。user テーブルの権限はグローバルであるため、別の権限テーブル エントリは不要です。

次の例示は、3 つのアカウントと作成し、それに特定のデータベースにアクセスできるようにします。それぞれに、custom というユーザ名と、obscure というパスワードがあります。

GRANT でこれらのアカウントを作成するには、次にステートメントを使用します。

shell> mysql --user=root mysql
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON bankaccount.*
    ->     TO 'custom'@'localhost'
    ->     IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON expenses.*
    ->     TO 'custom'@'whitehouse.gov'
    ->     IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON customer.*
    ->     TO 'custom'@'server.domain'
    ->     IDENTIFIED BY 'obscure';

この 3 つのアカウントを次のように使用します。

  • 最初のアカウントは、ローカル ホストからのみ、bankaccount データベースにアクセスできます。

  • 2 番目のアカウントは、whitehouse.gov というホストからのみ、expenses データベースにアクセスできます。

  • 3 番目のアカウントは、server.domain というホストからのみ、customer データベースにアクセスできます。

GRANT を使用しないで、custom アカウントをセットアップするには、 INSERT ステートメントを次のように使用して、権限テーブルを直接変更します。

shell> mysql --user=root mysql
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('localhost','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('whitehouse.gov','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('server.domain','custom',PASSWORD('obscure'));
mysql> INSERT INTO db
    ->     (Host,Db,User,Select_priv,Insert_priv,
    ->     Update_priv,Delete_priv,Create_priv,Drop_priv)
    ->     VALUES('localhost','bankaccount','custom',
    ->     'Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    ->     (Host,Db,User,Select_priv,Insert_priv,
    ->     Update_priv,Delete_priv,Create_priv,Drop_priv)
    ->     VALUES('whitehouse.gov','expenses','custom',
    ->     'Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    ->     (Host,Db,User,Select_priv,Insert_priv,
    ->     Update_priv,Delete_priv,Create_priv,Drop_priv)
    ->     VALUES('server.domain','customer','custom',
    ->     'Y','Y','Y','Y','Y','Y');
mysql> FLUSH PRIVILEGES;

最初から 3 つ目までの INSERT ステートメントは、user テーブル エントリを追加します。このエントリは、custom というユーザが、様々なホストから指定のパスワードで接続できますが、グローバル権限の記述はありません。(すべての権限はデフォルトの 'N' でセットになります。) 次の INSERT ステートメントの 3 つは、db テーブル エントリを追加します。このエントリは、custom に権限を与え、適切なホストからだけ bankaccountexpenses そして customer というデータベースのデータベースにアクセスできます。ここでも、権限テーブルを直接変更するときは、変更内容を反映させるために、FLUSH PRIVILEGES でサーバにリロードするよう指示してください。

特定のユーザで、mydomain.com など特定のドメインにすべてのマシンからアクセスできるようにする場合は、GRANT ステートメントを使用します。このステートメントは、アカウント名のホストの部分で ‘%’ ワイルドカード文字を使用します。

mysql> GRANT ...
    ->     ON *.*
    ->     TO 'myname'@'%.mydomain.com'
    ->     IDENTIFIED BY 'mypass';

直接、権限テーブルを変更して、同じことを行なうには、次のようにします。

mysql> INSERT INTO user (Host,User,Password,...)
    ->     VALUES('%.mydomain.com','myname',PASSWORD('mypass'),...);
mysql> FLUSH PRIVILEGES;

4.8.3. MySQL ユーザの削除

アカウントを削除するには、DROP USER ステートメントを使用します。これは、項12.5.1.2. 「DROP USER 構文」 を参照してください。

4.8.4. ユーザ リソースの制限

MySQL サーバ リソースの使用を制限することの一つの方法として、スタートアップ変数の max_user_connections をゼロ以外の値に設定することがあります。しかし、この方法は完全にグローバルに適用するため、個別アカウントの管理はできません。これに加えて、この方法は、単一アカウントによる同時接続の数を制限するものであり、これは クライアントが制限できることではありません。このようなタイプの制御は、インターネット サービス プロバイダ業界などでの MySQL 管理者に高い関心をよせる点です。

MySQL 5.1 では、個別ユーザレベルで 3 つのサーバ リソースを制限できます。

  • 時間単位の全クエリ数: 1 ユーザが実行できるクエリ

  • 時間単位の全更新数: テーブルまたはデータベースを変更するクエリ

  • 時間単位の接続数: 1 時間で新しく開ける接続

クライアントが発行できるステートメントはクエリ制限に対してカウントします。データベースまたはテーブルを変更するステートメントは更新制限に対してカウントします。

アカウント ベースでサーバへの同時接続の数を制限することも可能です。

ここでのアカウントは、user テーブル エントリの 1 レコード (ユーザ) です。このエントリは UserHost のカラム値で識別します。

ここでの機能を使用をするための前提条件として、mysql データベースの user テーブルには、リソース関連のコラム (フィールド) が必要です。リソース制限は、max_questionsmax_updatesmax_connectionsmax_user_connections のカラムで保存します。user テーブルにこれらのカラムがない場合は、項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照して、アップグレードしてください。

GRANT ステートメントでリソース制限を設定するには、WITH 節を使用します。この節は制限するリソースと制限値の時間単位の回数を指定します。たとえば、customer データベースにアクセスできる新規アカウントを作成するときに、制限をつける場合は、次のようなステートメントを発行します。

mysql> GRANT ALL ON customer.* TO 'francis'@'localhost'
    ->     IDENTIFIED BY 'frank'
    ->     WITH MAX_QUERIES_PER_HOUR 20
    ->          MAX_UPDATES_PER_HOUR 10
    ->          MAX_CONNECTIONS_PER_HOUR 5
    ->          MAX_USER_CONNECTIONS 2;

制限する種類をすべて WITH 節で指定する必要はありませんが、順番がバラバラになります。時間単位の制限値は時間単位を表す整数にします。GRANT ステートメントに WITH 節がない場合は、この制限はデフォルト値、ゼロでの設定になります。つまり、制限がないことになります。MAX_USER_CONNECTIONS の整数は、アカウントが一度にできる同時接続の最大回数を表します。この制限を、デフォルト (ゼロ) にした場合、max_user_connections システム変数でアカウント同時接続回数を決定します。

既存アカウントの制限をセットまたは変更するには、グローバル レベル (ON *.*) で GRANT USAGE ステートメントを使用します。 francis に対するクエリ制限を 100 に変更するステートメントは、次のようになります。

mysql> GRANT USAGE ON *.* TO 'francis'@'localhost'
    ->     WITH MAX_QUERIES_PER_HOUR 100;

このステートメントでは、アカウントにある既存の権限には影響しません。制限値の指定を行なうだけです。

既存の制限を削除するには、その値をゼロにセットします。たとえば、francis が時間当たり接続できる回数の制限を削除するには、次のステートメントを使用します。

mysql> GRANT USAGE ON *.* TO 'francis'@'localhost'
    ->     WITH MAX_CONNECTIONS_PER_HOUR 0;

リソース使用のカウントは、アカウントの対象制限でリソースの値がゼロではないときに行なわれます。

サーバを実行すると、それぞれのアカウントのリソース使用回数のカウントが始まります。前の接続時間内で接続の制限値に到達すると、それ以後の接続はその時間が過ぎるまで接続できません。同様に、そのアカウントでクエリまたは更新の制限回数に到達すると、それ以後のクエリや更新はその時間が過ぎるまでできません。制限値に到達すると、それぞれでエラーが出ます。

リソースのカウントは、アカウント単位に行います。クライアント単にではありません。たとえば、アカウントのクエリ制限が 50 である場合、サーバへの接続を同時に 2 つのクライアントから行なっても、制限が 100 になるという具合に、制限値が上がることはありません。この 2 つの接続からのクエリは一緒にカウントします。

クエリ キャッシュからのクエリ結果は、MAX_QUERIES_PER_HOUR のカウントにはなりません。

現行の時間単位のリソース利用のカウントは、すべてのアカウントに対して、または別々にグローバルでリセットできます。

  • すべてのアカウントに対して現行のカウントをゼロにリセットするには、FLUSH USER_RESOURCES ステートメントを発行します。また、このリセット操作は FLUSH PRIVILEGES ステートメントや mysqladmin reload コマンドを使用して、権限テーブルのリロードを行なうことでもできます。

  • アカウント単位でカウントを別々にゼロにリセットするには、制限値を再セットします。これを行なうには、前述の方法のように、GRANT USAGE を使用して、その時点でアカウントにある値と同等の別の値を指定します。

カウントのリセットを行なっても、MAX_USER_CONNECTIONS 制限には影響しません。

すべてのカウントはサーバ起動時にゼロで始まりますが、再起動した場合に、そのカウントが持ち越しになることはありません。

4.8.5. パスワードの設定

パスワードの設定には、コマンドラインで mysqladmin を使用します。

shell> mysqladmin -u user_name -h host_name password "newpwd"

このコマンドでリセットするパスワードのアカウントは、user テーブル エントリにあるアカウントのことです。これは、User カラムの user_name と、Host カラムにある接続クライアント ホストとに一致します。

SET PASSWORD ステートメントを発行して、アカウントにパスワードを設定する方法もあります。

mysql> SET PASSWORD FOR 'jeffrey'@'%' = PASSWORD('biscuit');

root など、mysql データベースへのアクセス権限があるユーザだけが、別のユーザのパスワードを変更することができます。匿名ユーザでなければ、自分のパスワードを FOR 節を省略することでパスワードの変更ができます。

mysql> SET PASSWORD = PASSWORD('biscuit');

アカウントにある現在の権限に影響を与えることなく、アカウントのパスワードを設定するには、GRANT USAGE ステートメントをグローバル レベル (ON *.*) で使用します。

mysql> GRANT USAGE ON *.* TO 'jeffrey'@'%' IDENTIFIED BY 'biscuit';

ここに前述した方法が、パスワードを設定するときの推奨のやり方ですが、user テーブルを直接に変更する方法を取ることも可能です。

  • 新規アカウント作成のパスワード指定方法 (Password カラムに値を指定)

    shell> mysql -u root mysql
    mysql> INSERT INTO user (Host,User,Password)
        -> VALUES('%','jeffrey',PASSWORD('biscuit'));
    mysql> FLUSH PRIVILEGES;
    
  • 既存アカウントのパスワード変更方法 (UPDATEPassword カラム値のセット)

    shell> mysql -u root mysql
    mysql> UPDATE user SET Password = PASSWORD('bagel')
        -> WHERE Host = '%' AND User = 'francis';
    mysql> FLUSH PRIVILEGES;
    

SET PASSWORDINSERTUPDATE などで、空白ではないパスワードのアカウントに設定する場合は、PASSWORD() 関数で暗号化します。user テーブルは、平分テキストではなく、暗号化形式でパスワードを保存するため、PASSWORD() の使用は不可欠です。これを忘れた場合には、パスワードを次のように設定します。

shell> mysql -u root mysql
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('%','jeffrey','biscuit');
mysql> FLUSH PRIVILEGES;

ここでは、'biscuit' というリテラルの値 を user テーブルにパスワードとして保存するという結果になっています。暗号化した値ではありません。ここで肝心なことは、jeffrey がそのパスワードでサーバ接続を試行したときに、そのパスワードの値が暗号化されるということです。つまり、user テーブルにある値とは異なった文字列で照会されるということです。'biscuit' というリテラルの文字列で保存しているところへ、暗号化された別の文字列で入ってくるため、サーバは接続を拒否します。

shell> mysql -u jeffrey -pbiscuit test
Access denied

パスワード設定を GRANT ... IDENTIFIED BY ステートメントまたは mysqladmin password コマンドで行なうときは、どちらのスクリプトでもパスワードの暗号化が自動的に行なわれます。そのため、この場合には、PASSWORD() 関数は不要です。

注意PASSWORD() の暗号化は、Unix のパスワード暗号化とは別物です。項4.8.1. 「MySQL ユーザ名とパスワード」 を参照してください。.

4.8.6. パスワードのセキュリティ

user 権限テーブルへのアクセスを一般ユーザには与えてはいけません。

MySQL サーバに接続するクライアント プログラムを実行するときには、別のユーザにそのパスワードを知られない最大の努力をしてください。ここでは、クライアント プログラムを実行するときに指定するパスワードの使用方法とともに、それぞれに付随するリスクについて説明します。

  • コマンドラインで -pyour_pass または --password=your_pass などのオプションを使用する。

    shell> mysql -u francis -pfrank db_name
    

    この方法は簡単ですが、安全ではありませんps などのシステム ステータス プログラムでパスワードが可視的になります。このようなプログラムは別のユーザがコマンドラインを呼び出す可能性があります。MySQL クライアントでは通常、初期シーケンス中にコマンドラインのパスワード引数をゼロで書き換えます。しかし、これには値が可視的になる微妙なインターバルがあります。SystemV Unix など、システムによっては、ps でパスワードが可視状態になる問題があるので、この方法はお勧めしません。

  • パスワード指定なしで、-p または --password オプションを使用する。(your_pass 値の指定を行なわない。)この場合、クライアントプログラムが端末からのパスワード入力を要求する。

    shell> mysql -u francis -p db_name
    Enter password: ********
    

    *’ 文字はパスワードの入力場所です。パスワードは入力時には表示しません。

    コマンドラインからパスワードを指定するよりも、この方法でパスワードを入力する方が安全です。これは別のユーザに対して可視的ではありません。しかし、このパスワード入力方法は、相互的に実行するプログラムだけで使用することをお勧めします。相互的ではない場合に、スクリプトからクライアントを呼び出すと、端末からパスワードを入力することができません。システムによっては、スクリプトの最初のラインが、読み込んだパスワードが不正確になる場合があります。

  • オプション ファイルにパスワードを保存する。Unix 例:ホーム ディレクトリにある .my.cnf ファイルの [client] にパスワードをリストする。

    [client]
    password=your_pass
    

    .my.cnf にパスワードを保存する場合、ファイルを自分以外の誰からにもアクセスができないようにします。ファイルのアクセス モードを 400 または 600 に設定して確証します。

    shell> chmod 600 .my.cnf
    

    項3.3.2. 「オプションファイルの使用」で、オプション ファイルに関する記述を参照してください。

  • MYSQL_PWD 環境変数でパスワードを保存する。この方法で MySQL パスワードを指定することは、非常に危険 です。ps のバージョンによっては、実行プロセスの環境を表示するオプションがあるため、MYSQL_PWD でパスワードを設定すると、ps を実行している別のユーザに露呈することになります。ps がないシステムでも、処理環境を別のユーザに露呈する可能性があります。項2.14. 「環境変数」 を参照してください。

結論としては、クライアント プログラムのプロンプトでパスワード確認するか、セキュリティを確保したオプション ファイルに適切にパスワードを指定することが、最も安全な方法です。

4.8.7. 接続安全

MySQLでは、 MySQL クライアントと Secure Sockets Layer (SSL) プロトコルを使用してるサーバ間での暗号化接続をサポートしています。このセクションでは、SSL 接続の使用方法について説明します。さらに、Windows での SSH セットアップ方法についても説明します。ユーザへの SSL 接続の要求方法については、項12.5.1.3. 「GRANT 構文」GRANT ステートメントの REQUIRE 節に関する記述を参照してください。

MySQL の標準設定では、高速化に重点を置いています。そのため、データの暗号化はクライアントとサーバ間での接続プロトコルを遅くするという理由から、デフォルト設定はしていません。暗号化データは、CPU を大幅に消費して、これはコンピュータに負荷を与えるため、MySQL タスクを遅らせる原因となります。しかし、セキュリティ上、暗号化接続を必要とするアプリケーションでは、暗号化してください。

MySQL では接続単位の暗号化接続が可能です。アプリケーションに応じて、通常の暗号化なしの接続、または SSL による安全な接続を使い分けることができます。

OpenSSL API を元にしたセキュリティ上、安全な接続には、MySQL C API を利用します。レプリケーションでは、この C API を使用して、マスタとサーバ間での接続においてセキュリティを確保しています。

4.8.7.1. SSL の基本概念

MySQL での SSL 使用方法を理解するために、まず、基本的な SSL と X509 概念について説明します。この基本概念をよく理解している場合は、このセクションを読み飛ばしてください。

MySQL のデフォルト設定では、クライアントとサーバ間の接続を暗号化していません。これは、ネットワークにアクセスできる者がデータの送受信を傍受する可能性があることを示します。場合によっては、送受信中にデータの変更 (改ざん) にまで及びます。そのため、クライアント プリグラムを呼び出すときには、--compress オプションを使用するなどして、クライアントとサーバ間のセキュリティを少しでも高めることをお勧めします。しかし、これはクラッカー対策としては十分ではありません。

公開ネットワークでの情報のやり取りでも安全性が求められ、基本的に暗号化なしの接続は危険です。暗号化とは、データを読めないようにするということであり、現在でも暗号化アルゴリズムには様々なセキュリティ対策が投じられています。暗号化メッセージの入れ替えやデータ再生の繰り返しなど、様々な攻撃に対応していく必要があります。

SSL とは、複数の異なる暗号化アルゴリズムを使用して、公開ネットワークで受信するデータの信頼性を保証するためのプロトコルです。SSL にはデータの変更、消失、および再生を検知するメカニズムがあります。さらに、X509 規格の ID 認証方式のアルゴリズムも組み込まれています。

X509 とは、インターネット上で ID 認証を可能にする規格です。これは、電子商取引アプリケーションで最も一般的に使用されています。基本的には、「認証局 (Certificate Authority)」 という組織が電子証明書を必要とする者に割り当てるという方法を取ります。証明書には、2 つの暗号化キー(公開キーと秘密キー)がある非対称暗号化アルゴリズムを使用しています。証明書の所有者は、他者に証明書を提示して自分の ID を証明します。証明書には、所有者の公開キーが含まれています。この公開キーで暗号化するデータは、これに対応している秘密キーがなければ解読できません。秘密キーは証明書の所有者が保持しています。

SSL、X509、および暗号化に関する詳細は、インターネット検索エンジンなどで情報検索してください。

4.8.7.2. SSL接続

MySQL サーバとクライアント プログラムの間で SSL 接続を行うには、まずシステムが OpenSSL または yaSSL のいずれかに対応しているか、そして、使用中の MySQL バージョンが SSL に対応しているかどうかを確認してください。

MySQL は、セキュリティを確保した接続を簡単に行うために、yaSSL とのバンドルになっています。(MySQL と yaSSL は同一のライセンス モデルを採用、OpenSSL は Apache のライセンス。) yaSSL 対応のプラットフォームには限りがありましたが、現在では、MySQL AB サポートのプラットフォームすべてで利用できます。

MySQL と SSL を扱うときの接続安全を確保するには、次の手順に従います。

  1. SSL 対応の MySQL のバイナリ配布を使用していない環境で、バンドルの yaSSL ライブラリではなくて、OpenSSL を使用するという場合は、まず OpenSSL をインストールする。(MySQL では OpenSSL 0.9.6 でテスト済。) OpenSSL は、http://www.openssl.org からインストールする。

  2. SSL 対応の MySQL のバイナリ配布を使用していない場合、MySQL のソース配布で SSL を使用できるように設定する。MySQL を設定するときは、configure スクリプトを次のように呼び出す。

    shell> ./configure --with-ssl
    

    ここでは、バンドルの yaSSL ライブラリを使用できるようにソース配布を設定している。OpenSSL を使用する場合には、OpenSSL ヘッダ ファイルとライブラリがあるデイレクトリのパスで --with-ssl オプションを指定する。

    shell> ./configure --with-ssl=path
    

    MySQL 5.1.11 より前のバージョンを使用している場合は、適切なオプションを使用して、使用する SSL ライブラリを選択する。

    yaSSL:

    shell> ./configure --with-yassl
    

    OpenSSL:

    shell> ./configure --with-openssl
    

    ノート: Unix 対応の yaSSL では、真の乱数を読み出すために、/dev/urandom または /dev/random のどちらかを用意する。Solaris 2.8 や HP-UX より前のバージョンンでの yaSSL に関する追加情報などは、Bug#13164 を参照のこと。

  3. 権限テーブルのアップグレードに、mysql.user テーブルの SSL 関連カラムを権限テーブルに含めていることを確認する。MySQL 4.0 より古いバージョンの権限テーブルでは、この作業が必要です。アップグレード手順は 項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照のこと。

  4. SSL 対応でサーバ バイナリをコンパイルしていることを確認するには、--ssl オプションで呼び出す。サーバが SSL 非対応の場合は、エラーが出る。

    shell> mysqld --ssl --help
    060525 14:18:52 [ERROR] mysqld: unknown option '--ssl'
    

    mysqld サーバが SSL 対応していることを確認するには、have_openssl システム変数を調べる。

    mysql> SHOW VARIABLES LIKE 'have_openssl';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | have_openssl  | YES   |
    +---------------+-------+
    

    SSL 接続対応であれば、値は YES。値が DISABLED である場合は、--ssl-xxx オプションで起動すると SSL 対応になるということ (このセクションの後述を参照のこと)。SSL 接続対応であれば、値は YES

SSL 接続を有効にするには、適切な SSL 関連コマンド オプションを使用します。(項4.8.7.3. 「SSL コマンド オプション」 を参照のこと。)

MySQL サーバを起動して、クライアントが SSL 経由で接続できるようにするには、キーを識別するオプションとサーバの接続確立に必要な証明ファイルを使用します。

shell> mysqld --ssl-ca=cacert.pem \
       --ssl-cert=server-cert.pem \
       --ssl-key=server-key.pem
  • ssl-ca で CA 証明書 を認識する。

  • ssl-cert で、サーバのパブリック キーを認識する。これをクライアントに送信すると、そこにある CA 証明書を認証する。

  • ssl-key がサーバ プライベート キーを認識する。

SSL 対応の MySQL サーバとの接続安全を確立するには、クライアント指定のオプションが、クライアントで使用するユーザ アカウントの SSL 条件に依存します。項12.5.1.3. 「GRANT 構文」REQUIRE 節に関する記述を参照してください。

アカウントに特別の SSL 条件がない場合、または REQUIRE SSL オプションを含む GRANT ステートメントでアカウントを作成している場合は、--ssl-ca オプションで、クライアント接続が安全に行えます。

shell> mysql --ssl-ca=cacert.pem

クライアント証明書の指定も必要な場合は、アカウントを REQUIRE X509 オプションを使用して作成します。そのとき、そのクライアントでも適切なクライアント キーと証明ファイルを指定する必要があります。これをしないと、サーバが接続を拒否します。

shell> mysql --ssl-ca=cacert.pem \
       --ssl-cert=client-cert.pem \
       --ssl-key=client-key.pem

これは、サーバに使用するものと同様のオプションであることを示します。ノート: CA 証明書が同じである必要があります。

クライアントで、サーバとの現在の接続で SSL を使用しているかどうかを決定します。ここでは、Ssl_cipher ステータス変数の値をチェックします。SSL を使用していない場合、Ssl_cipher の値は空白です。SSL を使用してる場合、値は空白ではありません。例示のようになります。

mysql> SHOW STATUS LIKE 'Ssl_cipher';
+---------------+--------------------+
| Variable_name | Value              |
+---------------+--------------------+
| Ssl_cipher    | DHE-RSA-AES256-SHA |
+---------------+--------------------+

mysql クライアントでは、STATUS または ★\s★ コマンドを使用して、SSL のラインをチェックします。

mysql> \s
...
SSL:                    Not in use
...

または

mysql> \s
...
SSL:                    Cipher in use is DHE-RSA-AES256-SHA
...

クライアント プログラム内で接続安全を確立するには、mysql_ssl_set() C API 関数を使用して、mysql_real_connect() 関数を呼び出す前に、適切な証明オプションをセットします。(項23.2.3.67. 「mysql_ssl_set() を参照のこと。) 接続を確立したら、mysql_get_ssl_cipher() を使用して、SSL が使える状態になっているかどうかを確認します。戻値が NULL ではない場合は、接続が安全であることを示し、SSL 暗号鍵を指します。戻値が NULL である場合は、SSL が使用できていないことを示します。項23.2.3.33. 「mysql_get_ssl_cipher() を参照してください。

4.8.7.3. SSL コマンド オプション

SSL 使用、証明ファイル、キー ファイル を指定するときに使用するオプションについて説明します。コマンドラインまたはオプション ファイルを使用します。このオプションは、SSL 対応の MySQL でのみ利用できるオプションです。(項4.8.7.2. 「SSL接続」 を参照のこと。) --master-ssl* オプションは、レプリケーションを行うときに、スレーブ サーバからマスタ サーバ間での安全接続を確保するときに使用します。(項5.1.3. 「レプリケーションのオプションと変数」 を参照のこと。)

  • --ssl

    サーバに SSL 接続の許可を指定するオプション。 クライアント プログラムに対しては、SSL を使用してサーバに接続することを許可する。 このオプションだけでは SSL 使用の接続を行うには不十分。 --ssl-ca--ssl-cert、および --ssl-key オプションも指定する必要がある。

    このオプションは、別の SSL オプションを上書きをするときなど、別の使い方をするのが一般的である。たとえば、SSL を使用しないと示すときなど。この使い方をするときは、--skip-ssl または --ssl=0 として指定する。

    注意: --ssl オプションの使用には、SSL 接続を 必要としない。たとえば、サーバまたはクライアントが SSL サポートをコンパイルしていない場合、通常の暗号化なしの接続になるだけである

    SSL を使用した接続を安全に指定するには、GRANT ステートメントに REQUIRE SSL 節を含めてアカウントをサーバに作成する。そして、そのアカウントでサーバに接続すると、サーバとクライアントの両方で SSL サポートの接続になる。

    REQUIRE 節は、別のSSL 関連オプションも有効にする。項12.5.1.3. 「GRANT 構文」 では、REQUIRE に関する記述を参照のこと。そこでは、REQUIRE オプションで作成したアカウントを使用して接続するクライアントで指定する必要がある SSL のコマンド オプションに関する詳細について記述している。

  • --ssl-ca=file_name

    信頼された SSL 認証局 (trusted SSL CA) の一覧があるファイルのパス。

  • --ssl-capath=directory_name

    PEM 形式の信頼された CA 証明書を保存しているディレクトリのパス。

  • --ssl-cert=file_name

    接続安全を確立するために使用する SSL 証明書ファイルの名前。

  • --ssl-cipher=cipher_list

    SSL 暗号化に使用できるサイファ (暗号) の一覧。 cipher_list は、openssl ciphers コマンドと同じ形式。

    例: --ssl-cipher=ALL:-AES:-EXP

  • --ssl-key=file_name

    接続安全を確立するために使用する SSL キー ファイルの名前。

  • --ssl-verify-server-cert

    クライアント プログラム用のオプション。サーバに接続するときに使用するホスト名に対して、サーバ証明書の Common Name 値を検証するようにするオプションで、一致しない場合には接続却下になる。この機能は、中間者攻撃対策として使用できる。この検証のデフォルトは無効。(MySQL 5.1.11 追加のオプション)

4.8.7.4. SSL 証明のセットアップ

このセクションでは、MySQL サーバとクライアントで使用する SSL 証明書とキー ファイル’ののセットアップ方法について説明します。最初の例では、コマンドラインから使用可能な簡略化した手順を示します。2 番目の例では、より詳細なスクリプトで表示しています。どちらの例でも、OpenSSL の一部の openssl コマンドを使用しています。

その次の例は、MySQL サーバとクライアントの証明書とキー ファイルを作成するときのコマンド セットです。openssl コマンドでいくつかのプロンプトに対応する必要があります。テストするには、Enter キー を使用します。プロダクション仕様には、空ではないレスポンスを用意します。

# Create clean environment
shell> rm -rf newcerts
shell> mkdir newcerts && cd newcerts

# Create CA certificate
shell> openssl genrsa 2048 > ca-key.pem
shell> openssl req -new -x509 -nodes -days 1000 \
         -key ca-key.pem > ca-cert.pem

# Create server certificate
shell> openssl req -newkey rsa:2048 -days 1000 \
         -nodes -keyout server-key.pem > server-req.pem
shell> openssl x509 -req -in server-req.pem -days 1000 \
         -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

# Create client certificate
shell> openssl req -newkey rsa:2048 -days 1000 \
         -nodes -keyout client-key.pem > client-req.pem
shell> openssl x509 -req -in client-req.pem -days 1000 \
         -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem

以下は、MySQL に SSL 証明書をセットアップする方法を示すスクリプト例です。

DIR=`pwd`/openssl
PRIV=$DIR/private

mkdir $DIR $PRIV $DIR/newcerts
cp /usr/share/ssl/openssl.cnf $DIR
replace ./demoCA $DIR -- $DIR/openssl.cnf

# Create necessary files: $database, $serial and $new_certs_dir
# directory (optional)

touch $DIR/index.txt
echo "01" > $DIR/serial

#
# Generation of Certificate Authority(CA)
#

openssl req -new -x509 -keyout $PRIV/cakey.pem -out $DIR/cacert.pem \
    -config $DIR/openssl.cnf

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ................++++++
# .........++++++
# writing new private key to '/home/monty/openssl/private/cakey.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL admin
# Email Address []:

#
# Create server request and key
#
openssl req -new -keyout $DIR/server-key.pem -out \
    $DIR/server-req.pem -days 3600 -config $DIR/openssl.cnf

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ..++++++
# ..........++++++
# writing new private key to '/home/monty/openssl/server-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL server
# Email Address []:
#
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:

#
# Remove the passphrase from the key (optional)
#

openssl rsa -in $DIR/server-key.pem -out $DIR/server-key.pem

#
# Sign server cert
#
openssl ca  -policy policy_anything -out $DIR/server-cert.pem \
    -config $DIR/openssl.cnf -infiles $DIR/server-req.pem

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName           :PRINTABLE:'FI'
# organizationName      :PRINTABLE:'MySQL AB'
# commonName            :PRINTABLE:'MySQL admin'
# Certificate is to be certified until Sep 13 14:22:46 2003 GMT
# (365 days)
# Sign the certificate? [y/n]:y
#
#
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated

#
# Create client request and key
#
openssl req -new -keyout $DIR/client-key.pem -out \
    $DIR/client-req.pem -days 3600 -config $DIR/openssl.cnf

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# .....................................++++++
# .............................................++++++
# writing new private key to '/home/monty/openssl/client-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL user
# Email Address []:
#
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:

#
# Remove a passphrase from the key (optional)
#
openssl rsa -in $DIR/client-key.pem -out $DIR/client-key.pem

#
# Sign client cert
#

openssl ca  -policy policy_anything -out $DIR/client-cert.pem \
    -config $DIR/openssl.cnf -infiles $DIR/client-req.pem

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName           :PRINTABLE:'FI'
# organizationName      :PRINTABLE:'MySQL AB'
# commonName            :PRINTABLE:'MySQL user'
# Certificate is to be certified until Sep 13 16:45:17 2003 GMT
# (365 days)
# Sign the certificate? [y/n]:y
#
#
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated

#
# Create a my.cnf file that you can use to test the certificates
#

cnf=""
cnf="$cnf [client]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/client-cert.pem"
cnf="$cnf ssl-key=$DIR/client-key.pem"
cnf="$cnf [mysqld]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/server-cert.pem"
cnf="$cnf ssl-key=$DIR/server-key.pem"
echo $cnf | replace " " '
' > $DIR/my.cnf

SSL 接続をテストするには、サーバを次のように立ち上げます。$DIR のあるところが、サンプルの my.cnf オプション ファイルがあるディレクトリのパスです。

shell> mysqld --defaults-file=$DIR/my.cnf &

同じオプション ファイルを使用して、クライアント プリグラムを呼び出します。

shell> mysql --defaults-file=$DIR/my.cnf

MySQL ソース配布がある場合、この my.cnf ファイルを変更して、セットアップしたものをテストすることができます。ソース配布の mysql-test/std_data ディレクトリにあるデモンストレーション用の証明書とキー ファイルを使用します。

4.8.7.5. SSH で Windows からリモート接続

SSH で 遠隔の MySQL サーバに安全接続を行う方法について説明します。(David Carlson 提供)

  1. まず、Windows マシンに SSH クライアントをイントールする。有償版では、http://www.vandyke.com/SecureCRT のもの、または http://www.f-secure.com/f-secure のものが妥当。無償版では、Googlehttp://directory.google.com/Top/Computers/Security/Products_and_Tools/Cryptography/SSH/Clients/Windows/ にあるものが妥当。

  2. Windows SSH クライアントを起動後、Host_Name = yourmysqlserver_URL_or_IP とする。そして、サーバへのログインには、userid=your_userid とする。userid という値は、MySQL アカウントのユーザ名とは別物。

  3. ポート転送をセットアップする。リモート転送は、local_port: 3306, remote_host: yourmysqlservername_or_ip, remote_port: 3306 として、ローカル転送は、port: 3306, host: localhost, remote port: 3306 とする。

  4. ここで、すべてを保存する。保存しない場合、次回に同じことを繰り返すことになる。

  5. 作り立ての SSH セッションでサーバにログインする。

  6. Windows のマシンで、 cess などの ODBC アプリケーションのどれかを立ち上げる。

  7. Windows で新規ファイルを作成して、通常と同じ方法で ODBC ドライバを使用して、MySQL にリンクする。ただし、MySQL ホスト サーバに localhost (yourmysqlservername) を入力しないこと。

この時点で、SSH を使用した暗号化で、MySQL との ODBC接続が確立する。

4.9. バックアップとリカバリ

このセクションでは、全体 (フル)そして増加分 (インクリメント) のデータベースのバックアップを行う方法を説明します。SQL ステートメントのシンタックスについては、章?12. SQL ステートメント構文 を参照してください。このセクションでは、MyISAM テーブルに関連した事柄について重点を置いています。InnoDB テーブルのバックアップ手順については、項13.5.8. 「InnoDB データベースのバックアップと復旧」 を参照してください。

4.9.1. データベースのバックアップ

MySQL テーブルはファイルとして保存するため、バックアップを簡単に行えます。整合性のあるバックアップを行うには、関連するテーブルで LOCK TABLES を行い、そのテーブルを FLUSH TABLES します。(項12.4.5. 「LOCK TABLESUNLOCK TABLES 構文」項12.5.5.2. 「FLUSH 構文」 を参照のこと。) 読み込みロックだけを行うため、データベース ディレクトリのファイル コピーを行う一方で、別のクライアントはテーブル照会を続けることができます。ここで、FLUSH TABLES ステートメントを必要とする理由は、バックアップを開始する前に、アクティブのインデックス ページすべてのディスクへの書き込みを確実に行うためです。

テーブルを SQL レベルでバックアップするには、SELECT INTO ... OUTFILE を使用します。ファイルの上書きはセキュリティ リスクに繋がるため、このステートメントでは既存のファイル名を指定する事は出来ません。項12.2.7. 「SELECT 構文」 を参照してください。

データベースをバックアップする別のテクニックとして、mysqldump または mysqlhotcopy script を使用する方法があります。項7.12. 「mysqldump ? データベースバックアッププログラム」項7.13. 「mysqlhotcopy ? データベースバックアッププログラム」 をそれぞれ参照してください。

  1. データベースのフル バックアップ方法

    shell> mysqldump --tab=/path/to/some/dir --opt db_name
    

    または

    shell> mysqlhotcopy db_name /path/to/some/dir
    

    サーバが更新作業中でなければ、バイナリ バックアップを *.frm*.MYD*.MYI などのテーブル ファイルをコピーする方法もある。そのときは、mysqlhotcopy スクリプト を使用する。ただし、データベースに InnoDB テーブルがある場合には、この方法でバックアップすることはできない。InnoDB にはデータベース ディレクトリにテーブル内容を保存していないため、mysqlhotcopy は、MyISAM テーブルの場合にだけ使用する。

  2. mysqld を実行している場合は、終了して、--log-bin[=file_name] オプションでこれを立ち上げる。(項4.11.4. 「バイナリ ログ」 を参照のこと。) バイナリ ログ ファイルには、mysqldump を実行したその時点から後のデータ変更を複製するときに必要な情報が入っている。

InnoDB テーブルに対して、オンライン バックアップはできますが、テーブルにはロックがありません。項7.12. 「mysqldump ? データベースバックアッププログラム」 を参照のこと。

MySQL の増加分バックアップ (インクリメント): バイナリ ロギングができるようにするために、サーバを --log-bin オプションで起動します。(項4.11.4. 「バイナリ ログ」 を参照のこと。) インクリメント バックアップを行う時点で、FLUSH LOGS を使用して、バイナリ ログをローテートします。 (このときのバックアップ内容とは、前回のフルまたはインクリメント バックアップをしてから発生した変更のことです。) ローテートを行った後、バックアップする部分をコピーします。この部分の範囲は、前回のバックアップ (フルまたはインクリメント) を行た時点を起点とし、このバックアップ操作を行う時点までを終点とします。つまり、追加部分です。(インクリメント バックアップには、リストアした時点でのバイナリ ログが 2 つあるということで、これは順次説明します。つまり、次回、フル バックアップを行うときも、FLUSH LOGSmysqldump --flush-logsmysqlhotcopy --flushlog のいずれかを使用してバイナリ ログのローテートが必要です。詳細は、項7.12. 「mysqldump ? データベースバックアッププログラム」項7.13. 「mysqlhotcopy ? データベースバックアッププログラム」 を参照のこと。)

MySQL サーバがレプリケーション スレーブである場合、どのようなバックアップの方法を取るとしても、スレーブのデータをバックアップするときには、master.inforelay-log.info の両ファイルをバックアップしてください。これらのファイルは、スレーブのデータをリストアするときに、レプリケーションのレジューム (再開) に必要です。スレーブが LOAD DATA INFILE コマンドを使用するレプリケーションの対象である場合、ディレクトリの SQL_LOAD-* ファイルもバックアップしてください。このファイルは、--slave-load-tmpdir オプションを指定すると出てきます。(このファイル位置を指定しない場合、この位置は tmpdir 変数の値 (デフォルト) になります。) このファイルは、LOAD DATA INFILE 操作が中断した場合などに、スレーブのレプリケーション再開で必要になります。

MyISAM テーブルをリストアする必要がある場合、まず REPAIR TABLE または myisamchk -r を使用して、リカバリしてください。この方法は、99.9% 確実です。myisamchk コマンドで失敗した場合は、次の手順を試行します。ノート: この方法は、MySQL を --log-bin オプションで立ち上げ、バイナリ ロギングを行っていた場合にだけ通用します。

  1. オリジナルの mysqldump バックアップ、またはバイナリ バックアップをリストアする。

  2. 次のコマンドを実行し、バイナリ ログの更新を再実行する。

    shell> mysqlbinlog binlog.[0-9]* | mysql
    

    場合によっては、特定の場所からのバイナリ ログだけを再実行する必要がある。通常は、バイナリ ログのすべてを再実行にはリストアしたバックアップの日から行うが、これには適切ではないステートメントが含まれている場合がある。項7.10. 「mysqlbinlog ? バイナリログファイルを処理するためのユーティリティ」 で、mysqlbinlog ユーティリティとその使用に関する詳細を参照のこと。

個別ファイルの部分的なバックアップを行う場合:

  • テーブルをダンプするには、SELECT * INTO OUTFILE 'file_name' FROM tbl_name を使用する。

  • テーブルをリロードするには、LOAD DATA INFILE 'file_name' REPLACE ... を使用する。テーブルに PRIMARY KEY または UNIQUE インデックスがあれば、レコードの重複を避けることができる。一意のキー値がある場合、REPLACE キーワードは、古いレコードが新しいものと入え替るので注意が必要。

バックアップするときにサーバにパフォーマンス上の問題が発生する場合、レプリケーションをセットアップして、マスタではなくスレーブ上でバックアップを実行することによりこの問題を解決できます。章?5. レプリケーション を参照のこと。

Veritas ファイルシステムを使用している場合、次の手順でバックアップを行います。

  1. クライアント プログラムから、FLUSH TABLES WITH READ LOCK を実行する。

  2. 別のシェルから、mount vxfs snapshot を実行する。

  3. 最初のクライアントから、UNLOCK TABLES を実行する。

  4. スナップショットからファイルをコピーする。

  5. スナップショットのマウントを解除する。

4.9.2. バックアップとリカバリ手法の例示

このセクションでは、クラッシュなどで、リカバリが必要にあるデータのバックアップ手順について説明します。クラッシュとは次に示す事柄です。

  • オペレーティング システムのクラッシュ

  • 停電

  • ファイルシステムのクラッシュ

  • ハードウェアの問題 (ハード ドライブ、マザーボードなど)

例示のコマンドには、mysqldump および mysql プログラムなどの --user および --password オプションなどは入っていません。MySQL サーバで接続が必要な場合などに応じて、そのようなオプションを追加してください。

ここでは、データが InnoDB ストレージ エンジンで保存しているものとします。つまり、トランザクションと自動クラッシュ リカバリのサポートがあるという前提です。このときの MySQL サーバには問題になる負荷がかかっているものとします。

オペレーティング システムのクラッシュまたは停電などの場合、MySQL のディスク データは再起動すると利用できるようになると考えられます。クラッシュすると InnoDB データ ファイルは、データの整合性を失う可能性がありますが、InnoDB はログを読み込み、まだデータ ファイルにフラッシュしていないコミット/非コミット トランザクションのリストを検索します。InnoDB は自動的にまだコミットしていないトランザクションをロール バックし、コミットしたものはデータ ファイルにフラッシュします。ユーザは、このリカバリ プロセスの情報をMySQL エラー ログから読むことができます。

InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
InnoDB: Doing recovery: scanned up to log sequence number 0 13805056
InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
...
InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections

ファイルシステムのクラッシュまたはハードウェアの問題などの場合は、MySQL のディスク データが 再起動しても利用可能にならない と考えられます。これは、ディスク データの一部はすでに読めない状態になっているため、MySQL は起動に失敗するという意味です。この場合、ディスクを再フォーマットする、または、新しいものをインストールする必要があります。放置すると、問題は解決しません。そして、バックアップから MySQL データのリカバリを行います。つまり、このときにはすでにバックアップを取っていることが必要です。このような場合を回避するためには、バックアップのポリシーをデザインしなければなりません。(次のセクションを参照のこと。)

4.9.2.1. バックアップ ポリシー

万が一に備えて、定期的にバックアップを取る必要があります。MySQL では、いくつかのツールを使用して、フル バックアップ (ある時点でのデータのスナップショット) を取ることができます。たとえば、InnoDB Hot Backup を使用すると、オンラインでブロックしていない InnoDB データ ファイルのフィジカル バックアップ (物理的) が取れ、 mysqldump を使用すると、オンラインのロジカル バックアップ (理論的) を取ることができます。このセクションでは、mysqldump について説明します。

MySQL Enterprise MySQL Network Monitoring and Advisory Service では、バックアップとレプリケーションに関する専門的なアドバイスを提供しています。詳細はhttp://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

負荷が少ない日曜の午後 1 時にバックアップを取ると仮定します。次のコマンドで、すべてのデータベースの InnoDB テーブルすべてをフル バックアップします。

shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql

これは、オンラインのバックアップをブロックしていない場合のため、テーブルの読み書き込みには影響しません。ここでは、バックアップ対象のテーブルが InnoDB であると仮定しているため、--single-transaction オプションでは整合性のあるデータ読み込みになり、mysqldump で使用したデータは変更しません。(クライアントによる InnoDB テーブルへの変更は、mysqldump プロセスで対象になっていません。) 異なる種類のテーブルもある場合には、そのテーブルがバックアップ中に変更しないものとします。たとえば、mysql データベースの MyISAM テーブルでは、バックアップ中に管理系の変更を MySQL のアカウントに対して行っていないものとします。

mysqldump による .sql ファイルには、後で使用するテーブル ダンプのリロードに使用する SQL INSERT ステートメントのセットが入ります。

フル バックアップは不可欠ですが、時間を要します。大きなバックアップ ファイルの生成には時間がかかります。前回のフル バックアップを行ってから全く変更のない部分も含めて、すべてのデータをフル バックアップを何度も行うことは最適化とはいえません。一度、フル バックアップを行ったら、次からは、インクリメント バックアップを行う方が効率的です。この方法であれば、負荷も減り、生成にかかる時間も短縮できます。トレードオフとしては、リカバリを行うときに、フル バックアップをリロードするだけではデータの回復にはならない、増加分にはインクリメント バックアップも使用して回復しなければならないという良し悪しがあります。

インクリメント バックアップを行うには、増加分/変更分 (インクリメント) を保存する必要があります。これには、MySQL サーバを常に --log-bin オプションで起動する必要があり、これにより、データ更新中に合わせて変更をファイルに保存できます。このオプションはバイナリ ロギングを可能にするものであるため、サーバは MySQL バイナリ ログというファイルに、データ更新に関するそれぞれの SQL ステートメントを書き込みます。ここで、数日間実行していた MySQL バイナリ ログ ファイルの例を次に示します。これは--log-bin オプションで起動した MySQL サーバのデータ ディレクトリのものです。

-rw-rw---- 1 guilhem  guilhem 1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem       4 Nov 10 23:59 gbichot2-bin.000002
-rw-rw---- 1 guilhem  guilhem      79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw---- 1 guilhem  guilhem     508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw---- 1 guilhem  guilhem 2247446 Nov 12 16:47 gbichot2-bin.000005
-rw-rw---- 1 guilhem  guilhem  998412 Nov 14 10:08 gbichot2-bin.000006
-rw-rw---- 1 guilhem  guilhem     361 Nov 14 10:07 gbichot2-bin.index

再起動する度に、MySQL サーバは新たなバイナリ ログ ファイルを作成します。これには連続する番号のシーケンスがあります。サーバを実行する一方で、そのサーバに使用中のバイナリ ログ ファイルを閉じて、新しいファイルを開始するように命令することができます。それには手動で、FLUSH LOGS SQL ステートメント、または mysqladmin flush-logs コマンドを使用します。mysqldump にもログをフラッシュするオプションがあります。ディレクトリの MySQL バイナリ ログのすべてのリストを含む .index というファイルがデータ ディレクトリにあります。このファイルはレプリケーションに使用します。

MySQL バイナリ ログでは、インクリメント バックアップのセットを形成しているため、リカバリでは重要になります。フル バックアップを行う場合に、ログのフラッシュを確実に行うと、それ以後のバイナリ ログ ファイルは変更した部分だけのデータを含むファイルになります。ここで、前述の mysqldump コマンドを若干修正すると、フル バックアップを行った時点でのMySQL バイナリ ログをフラッシュするようになります。つまり、ダンプ ファイルには新しいバイナリ ログの名前を含むようになります。

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases > backup_sunday_1_PM.sql

このコマンドを実行後、データ ディレクトリには gbichot2-bin.000007 という新しいバイナリ ログ ファイルができます。.sql ファイルは次のラインが入ります。

-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',≫
                    MASTER_LOG_POS=4;

mysqldump コマンドでフル バックアップを取っているため、これらのラインは 2 つの意味があります。

  • .sql ファイルは、gbichot2-bin.000007 というバイナリ ログ ファイル、またはそれ以降の新しいファイルに変更が書き込まれるよりも前の、すべての変更を含む。

  • バックアップ後にログしたデータのすべてが、.sql には存在しないが、gbichot2-bin.000007 というバイナリ ログ ファイル、または以降の新しいファイルに存在する。

そして、月曜の午後 1 時に、新しいバイナリ ログ ファイルでログを開始するために、それまでのログをフラッシュして、インクリメント バックアップを取ります。たとえば、mysqladmin flush-logs コマンドを実行して、gbichot2-bin.000008 というファイルを作成します。ここで、日曜の午後 1 時のフル バックアップを起点とし、月曜の午後 1 時までを終点とするすべての変更が、gbichot2-bin.000007 ファイルとなります。ここの手順で、このファイルには大事な役割があるので、コピーしてテープ、DVD、別のマシンなど安全な場所に保管しておきます。そして、翌日、火曜日の午後 1 時に、改めて、mysqladmin flush-logs コマンドを実行すると、gbichot2-bin.000008 ファイルが、月曜の午後 1 時を起点とし、火曜の午後 1 時を終点とするすべての変更を含むことになります。(これも安全な場所にコピーを保管します。)

MySQL バイナリ ログはディクス スペースを消費するので、必要に応じてスペースの解放が必要です。その 1 つの方法としては、たとえば、フル バックアップ後に不要なったバイナリ ログを削除します。

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases --delete-master-logs > backup_sunday_1_PM.sql

注意:サーバがレプリケーションのマスタ サーバである場合は、mysqldump --delete-master-logs というコマンドで MySQL バイナリ ログを 削除するということには危険が伴います。つまり、スレーブ サーバでまだバイナリ ログの内容を完全に処理し切れていない可能性があります。PURGE MASTER LOGS ステートメントの詳細 (項12.6.1.1. 「PURGE MASTER LOGS 構文」) で、MySQL バイナリ ログを削除する前の確認操作について参照してください。

4.9.2.2. バックアップ ファイルでリカバリ

(前セクションの続きです。) ここで、水曜日の午前 8 時に、バックアップを使用してリカバリを行う必要があるクラッシュが発生したとします。まず、前回のフル バックアップ (日曜午後 1 時のもの) をリストアします。フル バックアップのファイルは SQL ステートメントのセットであるため、リストアは簡単にできます。

shell> mysql < backup_sunday_1_PM.sql

ここで、データが日曜午後 1 時の時点での状態になります (リストア した。) 次に、これ以降に発生した変更についてもリストアします。つまり、インクリメント バックアップであるバイナリ ログ ファイル、gbichot2-bin.000007gbichot2-bin.000008 を使用します。必要に応じて、このファイルをバックアップしたところからフェッチして、その内容を次にように処理します。

shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

この時点で、データは火曜午後 1 時点の状態になります (リカバリできました。) しかし、まだクラッシュするまでのデータ (変更) が欠けています。まず、リカバリしたものを失くさないために保存します。このときは、MySQL サーバが、MySQL バイナリ ログで安全な場所に保存しなければなりません。RAID ディスク、SAN など、データ ファイルとは別の場所 (壊れていないディスク) に保管してください。この状態で、--log-bin を使用してサーバを起動すると、物理的には異なるデバイスのデータ ディレクトリから MySQL のログを立ち上げることができます。ここまでの作業 (リカバリしたものを保存) が完了したら、gbichot2-bin.000009 ファイル (クラッシュするまでのログ) で、mysqlbinlogmysql を適用して、クラッシュした時点までのデータ変更を失うことなく、最新のデータ変更をリストアできます。

4.9.2.3. バックアップ ストラテジーの概要

オペレーティング システムのクラッシュまたは停電の場合、InnoDB 自体がデータ リカバリに関するすべての作業を行います。しかし、万が一の対策として、次のガイドラインについて検討してください。

  • MySQL サーバは常に --log-bin オプションで起動する。ログ ファイル名がデータ ディレクトリがあるドライブではなく、安全用のメディアにある場合は、--log-bin=log_name を使用すること。安全対策用のメディアは、ディクスの負荷とのバランスを取るためにも、パフォーマンスの向上になる。

  • 定期的にフル バックアップを行う。項4.9.2.1. 「バックアップ ポリシー」 で示すように mysqldump コマンドを使用すると、オンラインでブロックなしのバックアップができる。

  • FLUSH LOGS または mysqladmin flush-logs などを使用して、ログをフラッシュして、インクリメント バックアップを定期的に取る。

4.9.3. 任意時点のリカバリ

MySQL サーバを --log-bin オプションで起動して、バイナリ ロギングを可能にしておくと、mysqlbinlog ユーティリティを利用して、起点と終点を指定して (例:前回バックアップをした時点から現在まで、など)、バイナリ ログ ファイルからデータのリカバリができます。mysqlbinlog を使用したバイナリ ログの有効化に関する詳細は、項4.11.4. 「バイナリ ログ」 および 項7.10. 「mysqlbinlog ? バイナリログファイルを処理するためのユーティリティ」 を参照してください。

MySQL Enterprise MySQL Network Monitoring and Advisory Service では、書き込みごとにディクスとの同期化し、データ リカバリを最大限活用するための情報を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

バイナリ ログからデータをリストアするには、まず、現行のバイナリ ログ ファイルの場所と名前を知る必要があります。デフォルトでは、サーバがデータ ディレクトリにバイナリ ログを作成していますが、パスは --log-bin を使用して、別の場所に指定することができます。通常、システムにもよりますが、オプションは my.cnf または my.ini などのオプション ファイルで与えます。サーバ起動時にコマンドラインから与えることも可能です。現行のバイナリ ログ ファイルの名前を確認するには、次のステートメントを発行します。

mysql> SHOW BINLOG EVENTS\G

または、コマンドラインから、次のコマンドを実行します。

shell> mysql -u root -p -E -e "SHOW BINLOG EVENTS"

mysql プロンプトで、サーバのroot パスワードを入力します。

4.9.3.1. リカバリの時刻指定

リカバリの開始/終了時刻を指定するには、DATETIME 形式で、mysqlbinlog--start-date--stop-date を指定します。たとえば、2005 年 4 月 20 日の午前 10:00 時に、何らかの SQL ステートメントの実行で大きなテーブルが削除された、とします。このテーブルとデータをリストアするには、前夜のバックアップをリストアして、次のコマンドを実行します。

shell> mysqlbinlog --stop-date="2005-04-20 9:59:59" \
         /var/log/mysql/bin.123456 | mysql -u root -p

このコマンドは、--stop-date オプションで指定した日時までのデータすべてをリカバリします。時間分の SQL ステートメントの大部分を探し当てることができない場合は、その部分のアクティビティをリカバリします。これを元に、mysqlbinlog を開始日時で再度実行します。次はその例です。

shell> mysqlbinlog --start-date="2005-04-20 10:01:00" \
         /var/log/mysql/bin.123456 | mysql -u root -p

このコマンドでは、午前 10:01 時以降にログした SQL ステートメントを再実行します。前夜のダンプ ファイルのリストアと、この 2 つの mysqlbinlog コマンドの組み合わせで、午前 10:00 時の一秒前までのすべてと、午前 10:01 以降のすべてのリストアします。このコマンドを使用するときは、指定する時間をログ ファイルで十分に確認してください。ログ ファイルを実行せずに、内容だけを表示するには、次のコマンドを使用します。

shell> mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql

そして、そのファイルをテキスト エディタなどで開けて、確認します。

4.9.3.2. リカバリの位置指定

リカバリの日時ではなく、ログの位置で指定するには、--start-position および --stop-position オプションを mysqlbinlog で使用します。これは、開始/終了時間のオプションと同様の使い方をします。日時の部分をログ位置の番号とします。ログのどの部分をリカバリするのかを位置で指定すると、より正確なリカバリができます。SQL ステートメントへのダメージが起きたときに、大量のトランザクションが発生していた場合などに有用です。位置番号を確認するには、予期していないトランザクションがあった時間帯で mysqlbinlog を実行します。このとき、結果を確認用にテキスト ファイルにリダイレクトします。この操作は次のように行います。

shell> mysqlbinlog --start-date="2005-04-20 9:55:00" \
         --stop-date="2005-04-20 10:05:00" \
         /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql

このコマンドは、/tmp ディレクトリのテキスト ファイルに小さく作成します。このテキスト ファイルには、有害な SQL ステートメントを実行した時間の SQL ステートメントがあります。このファイルをテキスト ファイルで開き、リピートすると害になるステートメントを探します。停止点と開始点に指定するバイナリ ログの位置を確認します。位置は、番号が後続する log_pos とラベルで見分けます。前回のバックアップ ファイルをリストアした後、この位置番号を使用して、バイナリ ログ ファイルを処理します。たとえば、次のようにコマンドを使用します。

shell> mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \
         | mysql -u root -p

shell> mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \
         | mysql -u root -p

最初のコマンドは停止位置までのトランザクションすべてをリカバリします。2 番目のコマンドは、開始位置からバイナリ ログの終わりまでのトランザクションすべてをリカバリします。mysqlbinlog の出力には SQL ステートメントを記録する前の SET TIMESTAMP ステートメントを含むため、リカバリしたデータおよび関連する MySQL ログはトランザクションを実行したオリジナルの時刻を反映します。

4.9.4. テーブル保守とクラッシュ リカバリ

このセクションでは、MyISAM テーブルをチェックまたは修復するための myisamchk について説明します。このテーブルには、データを保存する .MYD ファイル、.MYI ファイル、そしてインデックスがあります。myisamchk の基本的な背景に関しては、項7.4. 「myisamchk ? MyISAM テーブル メンテナンス ユーティリティ」 を参照してください。

myisamchk を使用して、データベース テーブルの情報を取得、またはチェック、修復、最適化を行います。順次に操作の仕方、テーブルの保守スケジュールのセットアップについて説明します。

myisamchk でのテーブルの修復は安全性に優れていますが、テーブルに対して多くの変更が伴う保守では、作業を始める前に バックアップを取ります。

インデックスに影響を与える myisamchk の操作は、FULLTEXT のインデックスをフル テキストのパラメータで再構築することになります。このパラメータは、MySQL サーバで使用する値との互換性があります。よって、この問題を回避するには、項7.4.1. 「myisamchk 一般的なオプション」 のガイドラインに従ってください。

場合によっては、myisamchk で、SQL ステートメントを使用して MyISAM テーブルの保守を行うことは通説より簡単です。

  • MyISAM テーブルのチェックまたは修復には、CHECK TABLE または REPAIR TABLE を使用。

  • MyISAM テーブルの最適化には、OPTIMIZE TABLE を使用。

  • MyISAM テーブルの分析には、ANALYZE TABLE を使用。

これらのステートメントは、mysqlcheck クライアント プログラムを利用して、直接に使用できます。これには、myisamchk に対するこれらのステートメントは、サーバがすべての作業を行うという利点があります。myisamchk で作業を行うときは、myisamchk とサーバの間でそのテーブルを同時に使用 (不要なやり取り) していないことを確認してください。詳細は、項12.5.2.1. 「ANALYZE TABLE 構文」, 項12.5.2.3. 「CHECK TABLE 構文」項12.5.2.5. 「OPTIMIZE TABLE 構文」項12.5.2.6. 「REPAIR TABLE 構文」 を参照してください。

4.9.4.1. myisamchk でクラッシュ リカバリ

このセクションでは、MySQL データベースのデータ破損に対するチェックと対処方法について説明します。テーブルが頻繁に破損する場合は、項B.1.4.2. 「What to Do If MySQL Keeps Crashing」 を参照するなどして、その原因究明を行い必要があります。

MyISAM テーブルが破損する原因に関する説明は、項13.4.4. 「MyISAM テーブルの問題点」 を参照してください。

外部ロックを無効にして mysqld を実行する場合 (MySQL 4.0 以降のデフォルト)、mysqldmyisamchk で同時にテーブルをチェックするときは、注意が必要です。myisamchk を実行している間は、mysqld を使用したテーブルへのアクセスできるのは自分だけであると確証できる場合は、テーブルのチェックを開始する前に、mysqladmin flush-tables を実行するだけで作業が行えます。もし確証できない場合は、テーブルのチェックするときに、mysqld を停止します。myisamchk でテーブルをチェックすると同時に、mysqld で更新を行っていると、テーブルが破損していなくても警告がでます。

外部ロックを有効にしてサーバを実行する場合は、myisamchk を使用していつでもテーブルをチェックできます。この場合、サーバが myisamchk で使用しているテーブルを更新しようとすると、サーバが myisamchk を優先して、待機します。

myisamchk をテーブルの修復または最適化に使用する場合は、mysqld サーバが目的のテーブルを使用していないことを常に確認してください。これは外部ロックを無効にしているときにも通用します。mysqld を停止できない場合は最低限として、myisamchk を実行する前に mysqladmin flush-tables を実行してください。サーバと myisamchk が同時にテーブルにアクセスすると、破損の原因になります

クラッシュ リカバリを行うときは、データベースにある MyISAM テーブルの tbl_name それぞれが、データベース ディレクトリ内の 3 つのファイルに対応していることを理解する必要があります。この 3 ファイルは次の通りです。

ファイル用途
tbl_name.frmテーブル定義ファイル
tbl_name.MYDデータ ファイル
tbl_name.MYIインデックス ファイル

この 3 ファイルは、様々な形で破損の原因に関係していますが、最も問題が発生するのは、データ ファイルとインデックス ファイルです。

myisamchk は、..MYD (データ)ファイルのコピーをレコードごとに生成します。修復の最終段階で古い .MYD ファイルを削除して、新規ファイルをオリジナルの名前に変更します。--quick を使用している場合、myisamchk ではテンポラリの .MYD ファイルを生成しません。その代わりに .MYD ファイルが正常であるとみなし、.MYD ファイルに手を加えずに新規インデックス ファイルだけを生成します。.MYD ファイルに問題があった場合は myisamchk が自動的に検知して修復を中止するため、この方法は安全です。2 つの --quick オプションを myisamchk に設定することもできます。この場合、myisamchk はいくつかのエラー(重複キーなど)でも中止しませんが、.MYD ファイルを修正して解決しようとします。通常、修復処理にディスクの空き容量では足りない場合にのみ、2 つの --quick オプション指定を利用します。その場合、少なくとも myisamchk を実行する前にバックアップを作成してください。

4.9.4.2. MyISAM テーブルのエラー チェック方法

MyISAM テーブルをチェックするには、次のコマンドを使用します。

  • myisamchk tbl_name

    このコマンドでエラーの99.99% を発見できる。これで発見できないエラーは、データファイルだけに関連する稀な破損 である。テーブルをチェックする場合、通常、myisamchk でオプションなし、または -s (silent) オプションを使用する。

  • myisamchk -m tbl_name

    このコマンドで エラーの 99.999% を発見できる。このコマンドを実行すると、最初にすべてのインデックス エントリのエラーをチェックして、次にすべてのレコードを読み込む。レコードのすべてのキーのチェック サムを計算し、その結果がインデックス ツリーのキーのチェックサムと一致するかどうかを確認する。

  • myisamchk -e tbl_name

    このコマンドを実行すると、すべてのデータを完全にチェックする(-e は 「extended check」' のこと)。それぞれのレコードのすべてのキーを読み取り、チェックし、正しいレコードを指しているかどうかを確認する。この操作は、キーが多い、大きなテーブルでは時間がかかる。myisamchk は通常、最初のエラーが見つかった時点で停止する。(停止しないで) 操作を続けるには、-v(verbose)オプションを追加すると、myisamchk は最大 20 のエラーを検出しするまで操作を続行する。

  • myisamchk -e -i tbl_name

    前述のコマンドと同類。-i オプションをつけると myisamchk で統計情報も出力する。

大抵の場合、テーブルのチェックには、テーブル名以外の引数なしのシンプルな myisamchk コマンドで対応できます。

4.9.4.3. テーブルの修復方法

このセクションでは、MyISAM テーブルへの myisamchk の使用方法について説明します。(拡張子: .MYI.MYD)

MyISAM テーブルのチェックと修復には、CHECK TABLEREPAIR TABLE などのステートメントを使用します (推奨)。詳細は、項12.5.2.3. 「CHECK TABLE 構文」 を参照してください。

テーブル破損の症状としては、クエリが予期せず中断したり、次のようなエラーが発生します。

  • tbl_name.frm is locked against change

  • Can't find file tbl_name.MYI (Errcode: nnn)

  • Unexpected end of file

  • Record file is crashed

  • Got error nnn from table handler

perror nnn を実行すると、エラーの詳細情報を取得できます。nnn はエラー番号です。次の例は、perror を使用した、テーブルに問題があることを示す一般的なエラーです。

shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired

ノート: エラー 135(no more room in record file)とエラー 136 (no more room in index file) は、簡単に直せるエラーではありません。この場合、ALTER TABLE を使用して MAX_ROWS または AVG_ROW_LENGTH テーブル オプションを値を修正してください。

ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

現行のテーブル オプション値がわからない場合は、SHOW CREATE TABLE を使用します。

この 2 つ以外のエラーが出る場合は、テーブルを修復します。 myisamchk で検出するときに、発生するエラーの原因を正します。

修復プロセスには、4 つの段階があります。Unix では、mysqld を実行する Unix ユーザに読み取り権限があることを確認します(この確認を行うユーザにもこれらのファイルへのアクセス権が必要)。ファイルを修正する必要がある場合は、書き込み権限も必要です。

このセクションでは、項4.9.4.2. 「MyISAM テーブルのエラー チェック方法」 で説明しているテーブル チェックで失敗した場合、または myisamchk の拡張機能を使用する場合の修復作業について説明しています。

myisamchk で行うテーブル保守のオプションに関しては、項7.4. 「myisamchk ? MyISAM テーブル メンテナンス ユーティリティ」 を参照してください。

コマンドラインからテーブルを修復する場合は、まず、mysqld サーバを停止します。ノート: リモート サーバで mysqladmin shutdown を実行するときは、mysqladmin を返しても、すべてのステートメント処理の停止、続いてすべてのインデックスの変更をディスクにフラッシュするまでの間、 mysqld が活動を続けます。

段階 1:テーブルのチェック

myisamchk *.MYI、または時間に余裕があれば myisamchk -e *.MYI を実行します。-s (silent) オプションを使用すると、不要な情報出力を抑制します。

mysqld サーバが停止している場合は、--update-state オプションを使用して myisamchk にテーブルで 「checked」 マークを付けるよう指定します。

myisamchk がエラーを返すテーブルだけを修復する場合は、段階 2 へ進みます。

チェック時に複雑なエラー(out of memory エラーなど)が発生した場合、あるいは myisamchk がクラッシュした場合、段階 3 へ進みます。

段階 2: 簡単で安全な修復

まず、myisamchk -r -q tbl_name を試行する。(-r -q は 「クイック リカバリ モード」 で実行するという意味。) これで、データ ファイルには触れずにインデックス ファイルの修復だけを行います。データ ファイルに必要なデータがすべて揃っていて、削除リンクがデータ ファイル内の正しい位置を指していれば、テーブルは正常に修復できます。この後は、次のテーブルの修復を開始します。失敗した場合は以下の手順を実行します。

  1. データフ ァイルのバックアップを作成する。

  2. myisamchk -r tbl_name を使用する。(-r は 「リカバリ モード」 で実行するという意味。) これは、不正なレコードとデータ ファイルから削除したレコードを取り除いて、インデックス ファイルを再構築する。

  3. 前のステップが失敗した場合、myisamchk --safe-recover . を使用する。セーフ リカバリ モードでは、対応できるケースが少ない、古いリカバリ形式を使用している。このケースは、通常のリカバリ モードでは行わない方法で、処理には時間がかかる。

ノート:

修復オペを高速化するには、myisamchk を実行するときの sort_buffer_size および key_buffer_size の変数の値を、利用可能システム メモリの 25 パーセント (1/4) で設定します。

修復時に複雑なエラー(out of memory エラーなど)が発生した場合、あるいは myisamchk がクラッシュした場合、段階 3 へ進みます。

段階 3: 困難な修復

インデックス ファイルの最初の 16KB ブロックが破損している、またはそこに不正な情報がある場合、あるいは、インデックス ファイルがない場合に、この段階に進みます。この場合、新しいインデックス ファイルを作成する必要があります。以下を実行してください。

  1. データ ファイルを安全な場所に移動する。

  2. テーブル記述ファイルを使用して、新しい(空白の)データとインデックスファイルを作成する。

    shell> mysql db_name
    mysql> SET AUTOCOMMIT=1;
    mysql> TRUNCATE TABLE tbl_name;
    mysql> quit
    
  3. 古いデータファイルを、新しく作成したデータファイルにコピーする。単に古いファイルを新しいファイルに移動するのではなく、万一に備えて元の場所にも残しておくこと。

そして、段階 2 に戻ります。これで、myisamchk -r -q が機能するはずです(無限ループにならないはずです)。

REPAIR TABLE tbl_name USE_FRM の SQL ステートメントを使用して、この手順を自動的に行うこともできます。REPAIR TABLE を使用すると、サーバがすべての作業を行うため、ユーティリティとサーバの間に不要なやり取りが起こる可能性はありません。項12.5.2.6. 「REPAIR TABLE 構文」 を参照してください。

段階 4: 非常に困難な修復

.frm という記述ファイルもクラッシュしている場合に、この手順に従います。ただし、テーブル作成後に記述ファイルが変更になることはないため、通常は発生しない状況です。

  1. バックアップから記述ファイルをリストアし、段階 3 に戻る。インデックス ファイルをリストアして段階 2 に戻ることも可能。後者の場合、myisamchk -r で起動する。

  2. バックアップがない場合でも、そのテーブルがどのように作成したかが正確にわかるときは、テーブルのコピーを別のデータベースに作成する。新しいデータ ファイルを削除してから、.frm 記述ファイルと .MYI インデックス ファイルを、その別のデータベースからクラッシュしたデータベースへ移動する。これで新しい記述ファイルとインデックス ファイルができ、.MYD データ ファイルは前のものがそのまま残る。段階 2 に戻り、インデックス ファイルを再構築する。

4.9.4.4. テーブルの最適化

断片化したレコードを結合したり、レコードの削除または更新によって発生した無駄なスペースを除去するには、myisamchk をリカバリモードで実行します。

shell> myisamchk -r tbl_name

同様に、SQL の OPTIMIZE TABLEステートメントを使用して、テーブルを最適化することもできます。OPTIMIZE TABLE はテーブルの修復とキー分析を行い、さらにインデックス ツリーをソートして、キー走査の処理速度を上げます。また、OPTIMIZE TABLE を使用した場合、サーバ側ですべての処理を行うため、ユーティリティとサーバ間で不要なやり取りが発生しません。項12.5.2.5. 「OPTIMIZE TABLE 構文」 を参照してください。

myisamchk には、テーブルのパフォーマンスを向上させるオプションが数多くあります。

  • --analyze, -a

  • --sort-index, -S

  • --sort-records=index_num, -R index_num

利用可能なオプションの詳細に関しては、項7.4. 「myisamchk ? MyISAM テーブル メンテナンス ユーティリティ」 を参照してください。

4.9.4.5. テーブル情報の取得

テーブルに関する情報またはその統計を取得するには、次に示すコマンドを実行します。これらの情報については後で詳しく説明します。

  • myisamchk -m tbl_name

    myisamchk を 「describe モード」 で実行し、テーブル情報を生成する。外部ロックが無効になっている MySQL サーバを起動した場合には、myisamchk は、実行中に更新があったテーブルに対してエラーを報告することがあるが、データ破壊の危険性はない。describe モードでmyisamchk がテーブルを変更することはない。

  • myisamchk -d -v tbl_name

    実行中の処理に関する詳細な情報を取得するには、-v 追加して、myisamchk を冗長モードで実行する。

  • myisamchk -eis tbl_name

    テーブルの最重要情報のみを表示する。このオペではテーブル全体を読み取るため、時間を要する。

  • myisamchk -eiv tbl_name

    -eis とほぼ同じ。このオプションを使用すると、進行中の処理 (それまでに何が行われたか) も表示する。

ここで、この 3 つのコマンドを使用した出力例を示します。テーブル内の任意データとインデックス ファイルのサイズに基づいています。

-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.MYD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.MYI

myisamchk -d の出力例

MyISAM file:     company.MYI
Record format:   Fixed length
Data records:    1403698  Deleted blocks:         0
Recordlength:    226

table description:
Key Start Len Index   Type
1   2     8   unique  double
2   15    10  multip. text packed stripped
3   219   8   multip. double
4   63    10  multip. text packed stripped
5   167   2   multip. unsigned short
6   177   4   multip. unsigned long
7   155   4   multip. text
8   138   4   multip. unsigned long
9   177   4   multip. unsigned long
    193   1           text

myisamchk -d -v の出力例

MyISAM file:         company
Record format:       Fixed length
File-version:        1
Creation time:       1999-10-30 12:12:51
Recover time:        1999-10-31 19:13:01
Status:              checked
Data records:            1403698  Deleted blocks:              0
Datafile parts:          1403698  Deleted data:                0
Datafile pointer (bytes):      3  Keyfile pointer (bytes):     3
Max datafile length:  3791650815  Max keyfile length: 4294967294
Recordlength:                226

table description:
Key Start Len Index   Type                Rec/key     Root Blocksize
1   2     8   unique  double                    1 15845376      1024
2   15    10  multip. text packed stripped      2 25062400      1024
3   219   8   multip. double                   73 40907776      1024
4   63    10  multip. text packed stripped      5 48097280      1024
5   167   2   multip. unsigned short         4840 55200768      1024
6   177   4   multip. unsigned long          1346 65145856      1024
7   155   4   multip. text                   4995 75090944      1024
8   138   4   multip. unsigned long            87 85036032      1024
9   177   4   multip. unsigned long           178 96481280      1024
    193   1           text

myisamchk -eis の出力例

Checking MyISAM file: company
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:  98%  Packed:   17%

Records:          1403698    M.recordlength:     226
Packed:             0%
Recordspace used:     100%   Empty space:          0%
Blocks/Record:   1.00
Record blocks:    1403698    Delete blocks:        0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

myisamchk -eiv の出力例

Checking MyISAM file: company
Data records: 1403698   Deleted blocks:       0
- check file-size
- check delete-chain
block_size 1024:
index  1:
index  2:
index  3:
index  4:
index  5:
index  6:
index  7:
index  8:
index  9:
No recordlinks
- check index reference
- check data record references index: 1
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 2
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
- check data record references index: 3
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
- check data record references index: 5
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 6
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 7
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 8
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 9
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:   9%  Packed:   17%

- check records and index references
*** LOTS OF ROW NUMBERS DELETED ***

Records:         1403698   M.recordlength: 226  Packed:          0%
Recordspace used:    100%  Empty space:     0%  Blocks/Record: 1.00
Record blocks:   1403698   Delete blocks:   0
Recorddata:    317235748   Deleted data:    0
Lost space:            0   Linkdata:        0

User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, ≫
Involuntary context switches 122798

次の説明において、myisamchk が生成する情報のタイプについて説明します。「Keyfile」 とはインデックス ファイルのことです。「Record」 と 「row」 はシノニムです。

  • MyISAM file

    MyISAM (インデックス) ファイルの名前

  • File-version

    MyISAM フォーマットのバージョン。現在は常に 2。

  • Creation time

    データ ファイルの作成日時。

  • Recover time

    インデックスまたはデータ ファイルを前回再構築した日時。

  • Data records

    テーブル内のレコード数。

  • Deleted blocks

    予約済み領域 (リザーブ) を占有している削除済み (デリート) のブロック数。 テーブルの最適化には、この領域を最小にする。項4.9.4.4. 「テーブルの最適化」 を参照のこと。

  • Datafile parts

    動的フォーマットに対して、存在するデータ ブロック数。断片化レコードがない最適化テーブルに対する Data records と同じ。

  • Deleted data

    領域を解放していない削除済みデータのバイト数。テーブルの最適化には、この領域を最小にする。項4.9.4.4. 「テーブルの最適化」 を参照のこと。

  • Datafile pointer

    データ ファイル ポインタのサイズ(バイト単位)。2、3、4、5 バイトのどれか。通常は 2 バイトで足りるが、現在のところ、MySQL で制御することはできない。固定テーブルでは、レコード アドレスのこと。動的テーブルでは、バイト アドレスのこと。

  • Keyfile pointer

    インデックス ファイル ポインタのサイズ(バイト単位)。1、2、3 バイトのどれか。通常のテーブルは 2 バイトで足りるが、MySQL で自動的に計算する。常にブロック アドレスのこと。

  • Max datafile length

    テーブルのデータ ファイル(.MYD ファイル)の最大長(バイト単位)。

  • Max keyfile length

    テーブルのインデックス ファイル(.MYD ファイル)の最大長(バイト単位)。

  • Recordlength

    それぞれのレコードで使用する領域サイズ(バイト単位)。

  • Record format

    テーブル レコードの格納形式。 上記の例では Fixed length を使用。 他に、Compressed および Packed がある。

  • table description

    テーブル内のすべてのキーの一覧。myisamchk コマンドで、それぞれのキーの低レベル情報を表示する。内容は次の通り。

    • Key

      キー番号。

    • Start

      インデックス部が始まるレコード内の位置。

    • Len

      インデックス部の長さ。パック数値の場合、これは常にそのカラムの全長となる。文字列の場合、文字列カラムのプリフィックスをインデックスにできるため、インデックス化したカラムの全長よりも短くなることがある。

    • Index

      unique または multip.(複数)。このインデックスで値の重複が認められているか (在るか) どうかを示す。

    • Type

      インデックス部のデータ型。packedstripped、または empty のいずれかの ISAM データ型。

    • Root

      ルート インデックス ブロックのアドレス。

    • Blocksize

      それぞれのインデックス ブロックのサイズ。デフォルトでは 1024 であるが、MySQLをソースから組む場合、コンパイル時に変更可能。

    • Rec/key

      オプティマイザで使用する統計値。このインデックスのキー値ごとのレコード数を示す。ユニーク キーの値は常に 1。これは、myisamchk -a で、テーブルをロード(または大きく変更)すると更新する。更新しない場合は、デフォルト値の 30 のまま。

    (1 番目と 2 番目の) 出力例示のテーブルに、table description の 9 番目のキーが 2 つある。これは、2 パートを持つマルチ パート キー であることを示す。

  • Keyblocks used

    使用しているキー ブロックのパーセント。例で使用しているテーブルは myisamchk で再構成したばかりであるため、値が非常に高い(理論的最大値に非常に近い)。

  • Packed

    MySQL がキー間で共通するサフィックスの部分をパックした割合。これは、CHARVARCHAR のカラム キーにのみ使用可能。名前のような長い文字列では、MySQLがパックして使用領域を大きく減らす。たとえば、3 番目の出力例示の、4 番目のキーは、10 文字長 (100%) であるのに対して、領域を 60 % パックした (6割減) という意味。

  • Max levels

    このキーの B-tree の深さ。長いキーがある大きなテーブルでは、値が高くなる。

  • Records

    テーブル内のレコード数。

  • M.recordlength

    レコードの平均の長さ。固定長レコードのテーブルでは、これは実際のレコード長となる。

  • Packed

    MySQLが節約したパーセント。Packed 値 (%) は、MySQL が文字列の最後 (suffix) を削除してできたスペース。

  • Recordspace used

    使用してデータ ファイルのパーセント。

  • Empty space

    使用していないデータ ファイルのパーセント。

  • Blocks/Record

    レコードごとの平均ブロック数(断片化レコードを構成するリンク数)。これは、固定形式テーブルでは常に 1.0。この値は可能な限り、1.0 に近くしておく。大きくなりすぎた場合は、myisamchk で再編成する。項4.9.4.4. 「テーブルの最適化」 を参照のこと。

  • Recordblocks

    使用しているブロック(リンク)数。固定形式では、レコード数と同じになる。

  • Deleteblocks

    削除したブロック(リンク)数。

  • Recorddata

    使用しているデータ ファイルのバイト数。

  • Deleted data

    削除した(使用していない)データ ファイルのバイト数。

  • Lost space

    失った領域の合計バイト数。レコード長さを短くして更新した場合の、短くなった領域分。

  • Linkdata

    ポインタが使用しているストレージ量の合計 (これを Linkdata 値 と呼ぶ)。動的テーブルの場合、レコード断片をポインタでリンクしている(それぞれ 4 から 7 バイト)。

テーブルを myisampackで圧縮している場合は、myisamchk -d を実行すると、それぞれのテーブル カラムに関する追加情報を出力します。この情報の詳細は 項7.6. 「myisampack ? 圧縮された、読み取り専用MyISAM テーブルを作成する。」 を参照してください。

4.9.4.6. テーブル保守計画

問題が発生する前に、テーブル チェックを定期的に行います (推奨)。MyISAM テーブルをチェックまたは修復するには、CHECK TABLE および REPAIR TABLE ステートメントを使用します。詳細は、項12.5.2.3. 「CHECK TABLE 構文」項12.5.2.6. 「REPAIR TABLE 構文」 を参照してください。

別の方法としては、myisamchk を使用してテーブル チェックを行います。保守を目的とする場合は、myisamchk -s を使用します。-s (--silent の短縮形)を使用すると、サイレントモードで myisamchk を実行でき、エラー発生部分のメッセージを出力します。

MyISAM のテーブル チェックには自動化をお勧めします。自動チェックを有効にしておくと、「予期していないテーブル クラッシュ」 などでマシンが更新中であるにもかかわらず、再起動した場合などに、それぞれのテーブルをチェックする手間を省いて、影響があったテーブルを探すことができます。MyISAM テーブルの自動化設定を行うには、サーバを --myisam-recover オプションで起動してください。詳細は、項4.2.2. 「コマンド オプション」 を参照してください。

テーブル チェックは日常的に行うことをお勧めします。MySQL AB では、一週間に一度、重要なテーブルに対して、cron コマンドを使用して確認作業を行っています。たとえば、crontab ファイルでは、次のようにしています。

35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI

この出力には、クラッシュしたテテーブルの情報が出るため、必要に応じて、確認や修復の作業ができます。

実際に、MySQL AB ではここ数年間、ハードウェアの故障以外のテーブル クラッシュは発生していないため、一週間に一度という頻度がその有効性を示しています。

MySQL AB 自体では、この方法でテーブル チェックを行っていますが、実際、ユーザがこの作業を行うときは、MySQL を完全に信用できると確証できるまでは、myisamchk -s を1 日 1 度、行うことをお勧めします。

VARCHARBLOBTEXT などのテーブルで、MyISAM テーブルを動的レコードで更新していたり、テーブルに削除できるレコードが沢山あっても、時々そのテーブルでデフラグやリクレーム (返還) を行なっていれば、MySQL テーブルの保守は簡単に行なえます。これができるようにするには、対象となるテーブルに OPTIMIZE TABLE を使用します。または、しばらくの間、mysqld サーバを停止することが可能な場合は、そのサーバを止めて、場所をデータ ディレクトリに置き換えて、次のコマンドを使用します。

shell> myisamchk -r -s --sort-index --sort_buffer_size=16M */*.MYI

4.10. MySQL のローカライズと国際的使用

このセクションでは、様々なキャラクタ セットを使用したサーバの設定方法について説明します。サーバのタイム ゾーンと接続ごとのタイム ゾーン対応の設定方法についても説明します。

4.10.1. データおよびソート用キャラクタ セット

MySQL のデフォルトでは、米国と西ヨーロッパに適したキャラクタセットの latin1 ( ISO-8859-1) 、そして、照合順序(コアレーション)はスウェーデン語およびフィンランド語に準拠している latin1_swedish_ci で、ソート を行います。

MySQL 標準バイナリは、--with-extra-charsets=complex でコンパイルしてます。そのため、標準プログラムで、latin1 とすべてのマルチ バイト キャラクタ セットを処理できます。必要なキャラクタ セットは、キャラクタ セットの定義ファイルからロードします。

キャラクタセットは、識別子、つまり名前に使用できる文字を決定します。そして、SELECT ステートメントの ORDER BY 節および GROUP BY 節で行うの文字列の照合順序 (コアレーション) も決定します。

キャラクタ セットの変更は、サーバ起動時に、--character-set-server オプションで行い、照合順序には、--collation-server オプションを使用します。照合順序は設定するキャラクタ セットと対応するように使用ます。(SHOW COLLATION ステートメントでキャラクタ セットに対応する照合順序を確認します。項4.2.2. 「コマンド オプション」 を参照してください。

利用可能なキャラクタセットは、 --with-charset=charset_name オプションと --with-extra-charsets=list-of-charsets | complex | all | none オプションを configure しているかどうか、そして SHAREDIR/charsets/Index のキャラクタ セット設定ファイルに依存します。項2.9.2. 「典型的な configure オプション」 を参照してください。

注意: MySQL の実行中にキャラクタ セットを変更すると、ソート順序が変わる可能性もあります。つまり、インデックスが正しい順序ではなくなる可能性があります。結果として、すべての MyISAM テーブルで myisamchk -r -q --set-collation=collation_name の実行が必要になります。

クライアントを MySQL サーバに接続すると、サーバがデフォルトのキャラクタ セットをクライアントに送ります。このクライアントは、サーバと接続するためにそのキャラクタ セットに切り替えます。

SQL クエリの文字列をエスケープする場合は、mysql_real_escape_string() を使用します。mysql_real_escape_string() は旧 mysql_escape_string() 関数と同じですが、最初のパラメータとして MYSQL 接続を扱うときに、適切なキャラクタ セットをアカウントにエスケープする場合に使用します。

サーバをインストールしたときのパス以外のパスで、クライアントをコンパイルしていて、MySQL をコンフィギャしたユーザがすべてのキャラクタ セットを MySQL のバイナリに組み込んでいない場合があります。そのときは、サーバがクライアントとは異なるキャラクタセットで実行していることを、クライアントに知らせ、必要なキャラクタセットがある場所を、クライアントに指定する必要があります。 それには、--character-sets-dir オプションを使用して、MySQL の動的キャラクタ セットを保存しているディレクトリのパスを示します。たとえば、次のようにオプション ファイルに示します。

[client]
character-sets-dir=/usr/local/mysql/share/mysql/charsets

または、クライアントに特定のキャラクタ セットの使用を強制することも可能です。

[client]
default-character-set=charset_name

しかし、このように指定することは、あまりありません。

4.10.1.1. ドイツ語のキャラクタ セット

MySQL 5.1 では、キャラクタ セットと照合順序は別々に指定します。つまり、ドイツ語照合でソートする場合などに、latin1 というキャラクタ セットを選択して、照合順序には、latin1_german1_ci または latin1_german2_ci を使用してソートする、ということです。よって、ドイツ語でソートするには、latin1_german1_ci を照合順序としてサーバを起動し、--character-set-server=latin1 および --collation-server=latin1_german1_ci のオプションを使用した設定になります。

照合順序の相違に関する情報は、項9.10.2. 「西ヨーロッパのキャラクタセット」 を参照してください。

4.10.2. 英語以外のエラーメッセージ

mysqld では、次の言語でエラーメッセージを出力できます。 チョコ語、デンマーク語、オランダ語、英語(デフォルト)、エストニア語、フランス語、ドイツ語、ギリシャ語、ハンガリー語、イタリア語、日本語、韓国語、ノルウェー語、新ノルウェー語、ポーランド語、ポルトガル語、ルーマニア語、ロシア語、スロバキア語、スペイン語、スウェーデン語。

特定の言語でエラー メッセージを表示する mysqld を起動するには、--language または -L オプションを使用します。オプション値に使用する言語名を指定するか、またはエラー メッセージ ファイルで指定します。次の通りです。

shell> mysqld --language=swedish

または

shell> mysqld --language=/usr/local/share/swedish

注意: 言語名はすべて小文字で指定します。

言語ファイルは、MySQL ベース ディレクトリの share/LANGUAGE (デフォルト)にあります。

サーバで生成するエラー メッセージの内容を変更も可能です。詳細は MySQL Internals のマニュアル (http://dev.mysql.com/doc/) を参照してください。MySQL を新しいバージョンにアップグレードするときには、それまで使用していたエラー メッセージに関わる変更も合わせて行ってください。

4.10.3. 新しいキャラクタ セットの追加

このセクションでは、MySQL へ新しいキャラクタ セットを追加する方法について説明します。この作業には、MySQL ソース配布が必要になります。キャラクタ セットがシンプルな場合と、コンプレックスな場合で、選択する手順が異なります。

  • キャラクタ セットが、ソートのために特殊文字照合ルーチンを必要とせず、マルチ バイト文字のサポートも必要なければ、シンプルと判断します。

  • どちらかを必要とする場合は、コンプレックスと判断します。

たとえば、latin1danish はシンプルですが、big5czech はコンプレックスです。

次の手順では、キャラクタ セットの名前を MYSET と前提とします。

シンプルなキャラクタセットの場合

  1. MYSETsql/share/charsets/Index ファイルの最後に追加し、これに一意の番号を割り当てる。

  2. sql/share/charsets/MYSET.conf という ファイルを作成する(sql/share/charsets/latin1.conf のコピーをベースとして使用可能)。

    ファイルの構文は、非常にシンプル

    • コメントは ‘#’ 文字で始まり、行の最後まで続く。

    • 単語は任意の数のスペースで区切る。

    • キャラクタ セットを定義するときは、すべての単語を 16 進数値とする。

    • ctype 配列は、最初の 257 語を占める。to_lower[]to_upper[]sort_order[] などの配列はそれぞれ、その後の 256 語を占める。

    配列に関する詳細は 項4.10.4. 「キャラクタ定義配列」 を参照してください。

  3. キャラクタ セット名を、configure.inCHARSETS_AVAILABLE リストおよび COMPILED_CHARSETS リストに追加する。

  4. 再設定してから、再コンパイルして、テストする。

コンプレックスなキャラクタ セットの場合

  1. MySQL ソース配布に strings/ctype-MYSET.c というファイルを作成する。

  2. MYSETsql/share/charsets/Index ファイルの最後に追加し、これに一意の番号を割り当てる。

  3. strings/ctype-big5.c など、既存の ctype-*.c ファイルの 1 つを見て、何の定義が必要か調べる。注意: ファイル内の配列名には、ctype_MYSETto_lower_MYSET などが必要。これは、シンプルなキャラクタ セットの配列に対応する。キャラクタ定義配列に関する詳細は 項4.10.4. 「キャラクタ定義配列」 を参照してください。

  4. ファイルの先頭付近に、次のようなコメントを置く。

    /*
     * This comment is parsed by configure to create ctype.c,
     * so don't change it unless you know what you are doing.
     *
     * .configure. number_MYSET=MYNUMBER
     * .configure. strxfrm_multiply_MYSET=N
     * .configure. mbmaxlen_MYSET=N
     */
    

    configure プログラムはこのコメントを使用して、自動的にキャラクタ セットを MySQL ライブラリに組み込む。

    必要に応じて、strxfrm_multiply のライン (文字列照合関数)、および mbmaxlen のライン (マルチバイト文字セット関数) を組み込む。これについては、後続のセクションで説明。

  5. そして、次の関数を作成する。

    • my_strncoll_MYSET()

    • my_strcoll_MYSET()

    • my_strxfrm_MYSET()

    • my_like_range_MYSET()

    配列照合に関する詳細は 項4.10.5. 「文字列照合サポート」 を参照してください。

  6. キャラクタ セット名を、configure.inCHARSETS_AVAILABLE リストおよび COMPILED_CHARSETS リストに追加する。

  7. 再設定してから、再コンパイルして、テストする。

より詳細な手順は、sql/share/charsets/README ファイルにあります。

MySQL 配布バージョンへのキャラクタ セットの組み込みを希望する場合には、MySQL internals の メーリングリストにパッチをメールしてください。メーリング リストに関する詳細は 項1.6.1. 「MySQL メーリング リスト」 を参照してください。

4.10.4. キャラクタ定義配列

to_lower[]to_upper[] は、キャラクタセットの各メンバに対応する、大文字と小文字を格納するシンプルな配列です。次に例を示します。

to_lower['A'] should contain 'a'
to_upper['a'] should contain 'A'

sort_order[] は、文字をどのような照合順序でソートするかを示すマップです。多くの場合(すべてのキャラクタセットについてではありませんが)、これは to_upper[] と同じです(ソートで大文字と小文字は区別しません)。MySQL は sort_order[] の値に基づいて文字をソートします。複雑なソート ルールに関しては、項4.10.5. 「文字列照合サポート」 の文字列照合に関する記述を参照してください。

ctype[] はビット値の配列で、1 文字が 1 要素です。注意: to_lower[]to_upper[]sort_order[] などは文字値でインデックス化しますが、ctype[] の場合は文字値 + 1 でインデックス化します。これは、EOF を処理することが必要だったときの古いレガシー (古い技術) です。

m_ctype.h に、次に示すビットマスク定義があります。

#define _U      01      /* Uppercase */
#define _L      02      /* Lowercase */
#define _N      04      /* Numeral (digit) */
#define _S      010     /* Spacing character */
#define _P      020     /* Punctuation */
#define _C      040     /* Control character */
#define _B      0100    /* Blank */
#define _X      0200    /* heXadecimal digit */

それぞれの文字の ctype[] エントリは、文字を指定するビットマスク値の組み合わせになる必要があります。たとえば、'A' は大文字(_U)であると同時に 16 進数(_X)でもあるため、ctype['A'+1] には次の値が含まれます。

_U + _X = 01 + 0200 = 0201

4.10.5. 文字列照合サポート

使用する言語のソート ルールが、シンプルな sort_order[] テーブルで処理するには複雑すぎる場合、文字列照合を行う必要があります。

現在のところ、これに関する最良のドキュメントは、すでに実装しているキャラクタ セットです。たとえば、big5czechgbksjistis160 などのキャラクタ セットを参照してください。

ファイル先頭の特殊コメントで、strxfrm_multiply_MYSET=N 値を指定する必要があります。N には、my_strxfrm_MYSET で文字列が大きくなれる最大比率(正の整数)を設定してください。

4.10.6. マルチ バイト文字サポート

マルチ バイト文字を含む新しいキャラクタ セットのサポートを追加する場合、マルチ バイト文字関数を使用する必要があります。

現在のところ、これに関する最良のドキュメントは、すでに実装しているキャラクタ セットです。たとえば、euc_krgb2312gbksjisujis などのキャラクタセットを参照してください。これらは、strings ディレクトリの ctype-charset_name.c ファイルに実装しています。

ソース ファイル先頭の特殊コメントで mbmaxlen_MYSET=N 値を指定する必要があります。N には、キャラクタ セット内の最大文字のバイト数を設定してください。

4.10.7. キャラクタ セットに関する問題

使用しているバイナリにコンパイルしていないキャラクタ セットを使用すると、いくつかの問題が発生する可能性があります。

  • プログラムが認識しているパスが、キャラクタセットを保存しているものとは異なるパスになる。(デフォルトは /usr/local/mysql/share/mysql/charsets)。これは、該当プログラムで --character-sets-dir オプションを使用すると解決する。

  • キャラクタ セットが動的にロードできないマルチ バイト キャラクタ セットである場合、そのキャラクタ セットをサポートするようにプログラムを再コンパイルする必要がある。

  • キャラクタ セットは動的なキャラクタ セットであるが、その設定ファイルがない。この場合、新しい MySQL 配布から、そのキャラクタ セットの設定ファイルをインストールする必要がある。

  • Index ファイルにキャラクタセットの名前がない場合に、プログラムが次のようなエラー メッセージを表示する。

    ERROR 1105: File '/usr/local/share/mysql/charsets/?.conf'
    not found (Errcode: 2)
    

    この場合、新しい Index ファイルを入手するか、または手動でキャラクタ セット名を追加する。

MyISAM テーブルに、 myisamchk -dvv tbl_name を使用すると、テーブルのキャラクタ セットの名前と番号を確認できます。

4.10.8. MySQL サーバのタイム ゾーン サポート

MySQL サーバにはいくつかのタイム ゾーンがあります。

  • システムのタイム ゾーン。サーバ起動時に、ホスト マシンのタイム ゾーンを使用して、system_time_zone システム変数で設定する。それ以降にこの値が変更することはない。

    起動時の MySQL Server のシステム タイム ゾーンは、mysqld_safe で、--timezone=timezone_name を使用する。または、mysqld を起動する前に、TZ 環境変数で設定する。--timezoneTZ の許容値は、システムに依存するため、OS のドキュメントを参照のこと。

  • サーバのカレント タイム ゾーン。time_zone のグローバル システム変数はサーバ稼動中のタイム ゾーンを示す。time_zone の初期値は、'SYSTEM' で、サーバとシステムのタイム ゾーンが同じであることを示す。

    サーバのタイム ゾーンの初期グローバル値は、コマンドラインで --default-time-zone=timezone オプションで起動するときに明示的に指定する。または、オプション ファイルに次のラインを使用する。

    default-time-zone='timezone'
    

    SUPER 権限がある場合は、ラインタイムで次のステートメントを使用して、サーバのタイム ゾーンにグローバル値を設定する。

    mysql> SET GLOBAL time_zone = timezone;
    
  • 接続毎のタイムゾーン。接続するそれぞれのクライアントには、time_zone 変数で与えられた、それぞれのタイム ゾーン セッティングがある。最初は、セッション変数の値が time_zone 変数の値になるが、クライアントは次のステートメントを使用して、それぞれのタイム ゾーンを指定できる。

    mysql> SET time_zone = timezone;
    

カレント セッションのタイム ゾーン セッティングは、時間との関わりが深いディスプレイやストレージのタイム値に影響します。これには、NOW() または CURTIME() などの関数で表示する値や、TIMESTAMP カラムに保存し、そこから読み出す値も含まれます。TIMESTAMP カラムの値は、ストレージでは現在のタイム ゾーンから UTC へ、読み出しでは UTC からカレントのタイム ゾーンに変換します。カレントのタイム ゾーン セッティングは、DATE, TIME, or DATETIME などのカラム値、または UTC_TIMESTAMP() 関数などによって表示する値には影響しません。

グローバルおよびクライアント指定のタイム ゾーンのカレント値は、次のように読み出します。

mysql> SELECT @@global.time_zone, @@session.time_zone;

timezone 値には、いくつかの形式があります。次に示す形式では文字区別はありません。

  • 'SYSTEM' 値は、システム タイム ゾーンと同じ値を示す。

  • UTC オフセットを示す文字列の値。たとえば、'+10:00' または '-6:00' など。

  • 指定したタイム ゾーンの値。たとえば、'Europe/Helsinki''US/Eastern''MET' など。指定したタイム ゾーンは、タイム ゾーンの情報テーブルが mysql データベースにあるときにだけ使用できる。

MySQL のインストール手順でタイム ゾーン テーブルを mysql データベースに作成しますが、そのときは、ロードまではしません。その前に、テーブルを作成する必要があります。MySQL 4.1.3 以降にアップグレードする場合は、mysql データベースを更新すると、そのテーブルを作成できます。アップグレードに関する手順は、項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照してください。次に、テーブル作成してから、タイム ゾーン テーブルをロードするまでの手順 (手動) を示します。

注意

タイム ゾーンの情報をロードは、情報が変更する場合に応じて、変更します。たとえば、夏時間を導入している米国、メキシコ、カナダでは 2007年に導入ルールが変更しました。そのような変更がある場合、古いルールを使用しているアプリケーションとの誤差がでるため、MySQL サーバの時間で使用している情報を維持するために、タイム ゾーン テーブルをリロードする必要があります。このセクションで後述のノートを参照してください。

システムに独自の zoneinfo データベース (タイム ゾーンの関するファイル セット) がある場合、mysql_tzinfo_to_sql プログラムを使用して、タイム ゾーン テーブルの充てんを行います。Linux、FreeBSD、Sun Solaris、Mac OS X などのシステムでは、通常、タイム ゾーンに関するファイルは、/usr/share/zoneinfo ディレクトリにあります。システムに zoneinfo データベースがない場合、このセクションで後述しているパッケージをダウンロードします。

mysql_tzinfo_to_sql プログラムをタイム ゾーン テーブルのリロードに使用します。コマンドラインで、zoneinfo ディレクトリへのパスを mysql_tzinfo_to_sql へ渡し、mysql プログラムに出力します。たとえば次のようにします。

shell> mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql

mysql_tzinfo_to_sql はシステム内のタイム ゾーン ファイルを読み、そこから SQL ステートメントを生成します。mysql でそのステートメントを処理して、タイム ゾーン テーブルにロードします。

mysql_tzinfo_to_sql コマンドを使用して、単一のタイム ゾーン ファイルをロードしたり、うるう秒 (リープ セカンド) の情報を生成することも可能です。

  • tz_name というタイム ゾーンに対応する単一のタイム ゾーン ファイル、tz_file をロードするには、次のように mysql_tzinfo_to_sql を呼び出す。

    shell> mysql_tzinfo_to_sql tz_file tz_name | mysql -u root mysql
    

    注意: この方法で、サーバが必要とする、それぞれの指定ゾーンのファイルを別々のコマンドでロードしてください。

  • うるう秒のカウントが必要な場合は、次のように、うるう秒の情報を初期化します。ここで tz_file をタイム ゾーン ファイルの名前とします。

    shell> mysql_tzinfo_to_sql --leap tz_file | mysql -u root mysql
    

Windows または HP-UX など、zoneinfo データベースを使用しないシステムの場合は、パッケージのタイム ゾーン テーブルを使用します。これは、MySQL Developer Zone からダウンロードできます。

http://dev.mysql.com/downloads/timezones.html

このタイム ゾーン パッケージには、 MyISAM のタイム ゾーン テーブル用に、.frm.MYD.MYI などのファイルが入っています。このテーブルを mysql データベースの一部にする必要があるため、そのファイルをMySQL サーバのデータ ディレクトリの mysql サブ ディレクトリに入れてください。そのときは、サーバを停止してから作業を行い、再起動してください。

警告: システムに zoneinfo データベースがある場合は、ダウンロード パッケージを使用してはいけません。MySQL とシステム アプリケーション間での時間に関わる処理に誤差が生じる原因になります。代わりに、mysql_tzinfo_to_sql ユーティリティを使用してください。

レプリケーションを行うときのタイム ゾーン セッティングに関する情報は、項5.4.1. 「レプリケーション機能と既知問題」 を参照してください。

タイム ゾーン変更に対応

タイム ゾーンのルールに変更があるときは、古いルールを使用しているアプリケーションでも調節が必要になります。タイム ゾーンのずれを回避するために、システムのタイム ゾーン情報がカレント(最新の時間)であることを確認してください。MySQL では、タイム ゾーンをカレントにする必要がある要素が 2 つあります。

  • MySQL サーバでタイム ゾーンを SYSTEM で設定している場合は、オペレーティング システムの時間が、MySQL で使用する時間の値に影響するため、オペレーティング システムが最新 (アップデート) のタイム ゾーンを使用していることを確認する必要がある。大抵のオペレーティング システムでは、アップデートやサービス パックで時間変更に対応している。時間変更に関するアップデートなどオペレーティング システムのベンダー ウェブサイトを確認する。インターネットのパブリック タイムでサーバを稼動させている場合、システムが自動的に調整を行う。

  • MySQL で特定のタイム ゾーンを使用する場合、mysql データベースのタイム ゾーン テーブルのアップデートを行う。システムに独自の zeroinfo データベースがある場合は、 zeroinfo データベース をアップデートする度に、このセクションで前述した手順に従って、MySQL のタイム ゾーン テーブルをリロードする。 zeroinfo データベースがない場合は、MySQL Developer Zone のアップデート情報に従う。アップデートがある場合は、ダウンロードして、カレントのタイム ゾーン テーブルと置き換える。

4.10.9. MySQL サーバのローケル サポート

MySQL 5.1.12 から、lc_time_names 変数で示すローケルで、日時や略記の表示に使用する言語を制御します。 この変数は、DATE_FORMAT()DAYNAME()MONTHNAME() 関数での出力に影響します。

ローケル名は、'ja_JP''pt_BR' などの POSIX 規格の値です。システムのローケル セッティングに関わらず、'en_US' をデフォルト値としますが、クライアントで lc_time_names 値を調べたり、その値をセットすることは可能です。次にその例を示します。

mysql> SET NAMES 'utf8';
Query OK, 0 rows affected (0.09 sec)

mysql> SELECT @@lc_time_names;
+-----------------+
| @@lc_time_names |
+-----------------+
| en_US           | 
+-----------------+
1 row in set (0.00 sec)

mysql> SELECT DAYNAME('2010-01-01'), MONTHNAME('2010-01-01');
+-----------------------+-------------------------+
| DAYNAME('2010-01-01') | MONTHNAME('2010-01-01') |
+-----------------------+-------------------------+
| Friday                | January                 | 
+-----------------------+-------------------------+
1 row in set (0.00 sec)

mysql> SELECT DATE_FORMAT('2010-01-01','%W %a %M %b');
+-----------------------------------------+
| DATE_FORMAT('2010-01-01','%W %a %M %b') |
+-----------------------------------------+
| Friday Fri January Jan                  | 
+-----------------------------------------+
1 row in set (0.00 sec)

mysql> SET lc_time_names = 'es_MX';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@lc_time_names;
+-----------------+
| @@lc_time_names |
+-----------------+
| es_MX           | 
+-----------------+
1 row in set (0.00 sec)

mysql> SELECT DAYNAME('2010-01-01'), MONTHNAME('2010-01-01');
+-----------------------+-------------------------+
| DAYNAME('2010-01-01') | MONTHNAME('2010-01-01') |
+-----------------------+-------------------------+
| viernes               | enero                   | 
+-----------------------+-------------------------+
1 row in set (0.00 sec)

mysql> SELECT DATE_FORMAT('2010-01-01','%W %a %M %b');
+-----------------------------------------+
| DATE_FORMAT('2010-01-01','%W %a %M %b') |
+-----------------------------------------+
| viernes vie enero ene                   | 
+-----------------------------------------+
1 row in set (0.00 sec)

関数で影響を受ける月日の名前は、utf8 から character_set_connection システム変数で指すキャラクタ セットに変換します。

lc_time_names に設定できるローケル値は次の通りです。

ar_AE: アラビア語 - アラブ首長国連邦ar_BH: アラビア語 - バーレーン
ar_DZ: アラビア語 - アルジェリアar_EG: アラビア語 - エジプト
ar_IN: アラビア語 - イランar_IQ: アラビア語 - イラク
ar_JO: アラビア語 - ヨルダンar_KW: アラビア語 - クウェート
ar_LB: アラビア語 - レバノンar_LY: アラビア語 - リビア
ar_MA: アラビア語 - モロッコar_OM: アラビア語 - オマーン
ar_QA: アラビア語 - カタールar_SA: アラビア語 - サウジ アラビア
ar_SD: アラビア語 - スーダンar_SY: アラビア語 - シリア
ar_TN: アラビア語 - チュニジアar_YE: アラビア語 - イエメン
be_BY: ベラルーシ語 - ベラルーシbg_BG: ブルガリア語 - ブルガリア
ca_ES: カタロニア語 - カタロニア (スペイン、アンドラ)cs_CZ: チェコ語 - チェコ共和国
da_DK: デンマーク語 - デンマークde_AT: ドイツ語 - オーストリア
de_BE: ドイツ語 - ベルギーde_CH: ドイツ語 - スイス
de_DE: ドイツ語 - ドイツde_BE: ドイツ語 - ルクセンブルグ
EE: エストニア語 - エストニアen_AU: 英語 - オーストラリア
en_CA: 英語 - カナダen_GB: 英語 - 英国 (UK)
en_IN: 英語 - インドen_NZ: 英語 - ニュージーランド
en_PH: 英語 - フィリピンen_US: 英語 - アメリカ
en_ZA: 英語 - 南アフリカen_ZW: 英語 - ジンバブエ
es_AR: スペイン語 - アルゼンチンes_BO: スペイン語 - ボリビア
es_CL: スペイン語 - チリes_CO: スペイン語 - コロンビア
es_CR: スペイン語 - コスタリカes_DO: スペイン語 - ドミニカ共和国
es_EC: スペイン語 - エクアドルes_ES: スペイン語 - スペイン
es_GT: スペイン語 - グアテマラes_HN: スペイン語 - ホンジュラス
es_MX: スペイン語 - メキシコes_NI: スペイン語 - ニカラグア
es_PA: スペイン語 - パナマes_PE: スペイン語 - ペルー
es_PR: スペイン語 - プエルトリコes_PY: スペイン語 - パラグアイ
es_SV: スペイン語 - エル サルバドルen_US: スペイン語 - アメリカ
es_UY: スペイン語 - ウルグアイes_VE: スペイン語 - ベネズエラ
eu_ES: バスク語 - バスク (スペイン)fi_FI: フィンランド語 - フィンランド
fo_FO: フェロー語 - フェロー諸島fr_BE: フランス語 - ベルギー
fr_CA: フランス語 - カナダfr_CH: フランス語 - スイス
fr_FR: フランス語 - フランスfr_LU: フランス語 - ルクセンブルグ
gl_ES: ガリシア語 - ガリシア (スペイン)gu_IN: グジャラート語 - インド
he_IL: ヘブライ語 - イスラエルhi_IN: ヒンディー語 - インド
hr_HR: クロアチア語 - クロアチアhu_HU: ハンガリー語 - ハンガリー
id_ID: インドネシア語 - インドネシアis_IS: アイスランド語 - アイスランド
it_CH: イタリア語 - スイスit_CH: イタリア語 - イタリア
ja_JP: 日本語 - 日本ko_KR: 韓国語 - 韓国
lt_LT: リトアニア語 - リトアニアlv_LV: ラトビア語 - ラトビア
mk_MK: マケドニア語 - マケドニア・旧ユーゴスラビア (FYROM)mn_MN: モンゴル語 - モンゴル
ms_MY: マレー語 - マレーシアnb_NO: ボークモール語 - ノルウェー
nl_BE: オランダ語 - ベルギーnl_NL: オランダ語 - オランダ
no_NO: ノルウェー語 - ノルウェーpl_PL: ポーランド語 - ポーランド
pt_BR: ポルトガル語 - ブラジルpt_PT: ポルトガル語 - ポルトガル
ro_RO: ルーマニア語 - ルーマニアru_RU: ロシア語 - ロシア
ru_UA: ロシア語 - ウクライナsk_SK: スロバキア語 - スロバキア
sl_SI: スロベニア語 - スロベニアsq_AL: アルバニア語 - アルバニア
sr_YU: セルビア語 - ユーゴスラビアsv_FI: スウェーデン語 - フィンランド
sv_SE: スウェーデン語 - スウェーデンta_IN: タミル語 - インド
te_IN: テルグ語 - インドth_TH: タイ語 - タイ
tr_TR: トルコ語 - トルコuk_UA: ウクライナ語 - ウクライナ
ur_PK: ウルドゥー語 - パキスタンvi_VN: ベトナム語 - ベトナム
zh_CN: 中国語 - 中国zh_HK: 中国語 - 香港 SAR
zh_TW: 中国語 - 台湾?

現在のところ、lc_time_names には STR_TO_DATE() または GET_FORMAT() 関数との関係はありません。

4.11. MySQL サーバ ログ

MySQL には様々なログ ファイルがあり、mysqld 内での出来事を調べることができます。

ログ ファイル説明
エラー ログmysqld の起動、実行、および停止で発生した問題。
一般クエリログクライアントとの接続と実行したクエリ。
バイナリ ログデータ変更のステートメント。レプリケーションにも使用。
スロー クエリ ログlong_query_time 秒より時間を要したクエリ、またはインデックスを使用しなかったクエリ。

デフォルトでは、mysqld データ ディレクトリにすべてのログ ファイルを作成します。mysqld を行使して、ログ ファイルの開閉、置換を行います。FLUSH LOGS ステートメント、または mysqladmin flush-logs あるいは mysqladmin refresh などのコマンドで、ログをフラッシュします。詳細は 項12.5.5.2. 「FLUSH 構文」 および 項7.9. 「mysqladmin ? MySQL サーバの管理を行うクライアント」 を参照してください。

MySQL のレプリケーション機能を活用している場合、スレーブ レプリケーション サーバで、リレー ログというログ ファイルを保管しています。リレー ログおよびコンフィギュレーションに関しては、章?5. レプリケーション を参照してください。

MySQL 5.1.6 から、サーバで一般クエリとスロー クエリのエントリをログ テーブル、ログ ファイル (またはこの両方) に書き込むようになりました。詳細は 項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 を参照してください。

MySQL 5.1.12 からは、一般クエリとスロー クエリ ログのランタイム制御に追加機能があります。ロギングを有効化、無効化、そしてログ ファイルの変更などが行えます。詳細は 項4.11.3. 「一般クエリ ログ」 および 項4.11.5. 「スロー クエリ ログ」 を参照してください。

4.11.1. 一般クエリとスロー クエリのログ出力先の選択

MySQL 5.1.6 前は、サーバではログ ファイルが一般クエリとスロー ログ クエリのエントリとして機能しています (有効の場合)。MySQL 5.1.6 からは、サーバで、柔軟性があるログ出力先の制御ができます。従来通り、ログ エントリをログ ファイルに書き込みますが、mysql データベースの general_log そして slow_log のテーブルにもエントリを書き込むことができます。ロギングを有効にすると、テーブルの出力先を選択することができます。両方選択することも可能です。

ロギングを有効にすると、--log-output オプションでログ出力先を指定できます。このオプションは、次のように --log-output[=value,...] というシンタックスの使い方をします。

  • 値を --log-output で指定すると、この値はカンマ区切りのリストになります。TABLE はログからテーブルへの出力、FILE はログからファイルへの出力。NONE はテーブルやファイルにログしないときに使用し、これはどのような指定子よりも優先になる。

  • --log-output を値なしで使用する、または省略すると、その効果は --log-output=TABLE に同じ。つまり、テーブルの出力先の選択が行われる、ということ。 これは、MySQL 5.1.6 前のファイルを使用したデフォルトの出力先とは異なる。

  • --log-output オプションは、log_output グローバル システム変数の値を指す。これはランタイムで変更ができ、実行中のサーバのログ先を変更できる。

注意

MySQL 5.1.6 以上のインストールでは、ログ テーブルをシステム テーブルなどと一緒に作成します。MySQL を 5.1.6 より古いリリース バージョンから MySQL 5.1.6 以上にアップグレードするときは、アップグレードを行なった後に、ログ テーブルがあるかどうかを確認するために、システム テーブルのアップグレードも行ってください。

MySQL 5.1.6 より、デフォルトのログ先がファイルからテーブルに変更します。ロギングをログ ファイルで行う設定になっている場合は、その設定を保存するために、5.1.6 以上にアップグレードを行なってから、--log-output=FILE を使用します。

--log[=file_name] を使用すると、一般クエリ ログのログ先を選択式で変更して、ロギングができます。同様に、--log-slow-queries[=file_name] を使用すると、スロー クエリ ログも選択式でログ先を変更できます。どちらのオプションでも、FILE の出力先を指定しない限り、ファイル名は無視になります。

--log または --log-slow-queries を指定する場合は、サーバが関連ログ ファイルを開き、スタートアップ メッセージを書き込みますが、ファイルへのクエリのロギングは、FILE ログ先を選択するまで始まりません。

例:

  • 一般クエリ エントリをログ テーブルとログ ファイルに書き込むには、--log-output=TABLE,FILE を使用して、両方の出力先を選択して、--log オプションで、一般クエリ ログを返す。

  • 一般クエリとスロー クエリのログをログ テーブルにだけ書き込むには、--log-output=TABLE でログ先のテーブルを選択し、--log--log-slow-queries で両方のログを有効にする。この場合、デフォルトのログ出力先が TABLE になっているため、--log-output オプションを省略することも可能。

テーブルでのログ出力には、次のような利点があります。

  • ログ エントリが標準形式になる。ログ テーブルの現行のストラクチャを表示するには、次のステートメントを使用する。

    SHOW CREATE TABLE mysql.general_log;
    SHOW CREATE TABLE mysql.slow_log;
    
  • ログ内容は、SQL ステートメントでアクセス可能。これは、特定のクライテリアを充たすエントリを選択するという、クエリの使い方をすることができる。たとえば、特定のクライアントに関連するログ内容を選択することが簡単になるということ。これは、クライアントからの問題があるクエリを識別するときに役立つ。

  • サーバに接続し、クエリを出すクライアントからログにリモート アクセスできる。(これには、クライアントに適切なテーブル権限が必要。) サーバ ホストへのログイン、またはファイルシステムへの直接アクセスが不要になる。

  • TRUNCATE TABLE を使用して、ログ エントリに有効期限をつけることができる。

デフォルトでは、ログ テーブルへのデータ書き込みは CSV ストレージ エンジンへ、カンマ区切り形式で行います。ログ テーブルにデータがある .CSV ファイルへのアクセスができるユーザは、CSV を処理する表計算など別のプログラムへファイルを簡単にインポートできます。

MySQL 5.1.12 から、ログ テーブルは MyISAM ストレージ エンジン (メモリ) での使用に変更できます。使用中のログ テーブルを変更するために、ALTER TABLE を使用することはできません。その場合は、まずログを停止してください。ログ テーブルのエンジン (メモリ) には、CSV または MyISAM だけを使用してください。

ログ テーブルに DROP TABLE を使用することも同様に禁止です。使用中のログ テーブルをドロップすることはできません。まず、ログを停止してください。

ログを停止してから、ログ テーブルを変更するには、次の方法を取ります。

SET @old_log_state = @@global.slow_query_log;
SET GLOBAL slow_query_log = 'OFF';
ALTER TABLE mysql.slow_log ENGINE = MyISAM;
SET GLOBAL slow_query_log = @old_log_state;

MySQL 5.1.12 から、FLUSH TABLES ではログ テーブルを出力しません。ログ テーブルをフラッシュするには、FLUSH LOGS を使用してください。

MySQL 5.1.13 から、ログのローテーションを行うときなどに、ログ テーブルをアトミックに改名できます。それには、次の方法を取ります。

USE mysql;
CREATE TABLE IF NOT EXISTS general_log2 LIKE general_log;
RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log;

4.11.2. エラー ログ

エラーログファイルでは、mysqld の起動時刻と停止時刻、および実行中に発生したエラーに関する情報を記録しています。自動でチェックまたは修復が必要なテーブルを mysqld で見つけた場合には、エラー ログに警告メッセージが書き込まれます。

オペレーティング システムによっては、エラー ログに mysqld が異常終了した場合のスタック トレースを記録しています。そのため、このトレースを mysqld が動かなくなった場合の確認に使用できます。スタック トレースに関しては Using a Stack Trace を参照してください。

mysqld_safe を使用して、mysqld を起動したときに、 mysqld が異常終了する場合は、mysqld_safe がそれを認識し、mysqld を再起動する必要があることを、restarted mysqld メッセージとして、エラー ログに書き込みます。

mysqld を保存するエラー ログ ファイルは、--log-error[=file_name] オプションで指定できます。file_name を指定しない場合は、mysqld で、host_name.err という名前を使用して、データ ディレクトリに書き込みます。そして、FLUSH LOGS を実行するときに、エラー ログは -old というサフィックスでの改名になり、mysqld が新たな空ログ ファイルを作成します。(--log-error で指定しないと、名前の変更は起こりません。)

--log-error を指定しない場合、または Windows 環境である場合に、--console オプションを使用すると、エラーは stderr という標準のエラー出力で端末書き込みになります。

Windows では、--console の指定がない限り、エラー出力は .err ファイルへの書き込みになります。

--log-warnings オプション、または log_warnings システム変数を使用すると、エラー ログの警告ロギングを制御できます。値を 1 (デフォルト) にすると、有効化し、0 にすると無効化します。値を 1 より大きな値にすると、中断した接続についてもエラー ログを記録します。詳細は、項B.1.2.10. 「Communication Errors and Aborted Connections」 を参照してください。

4.11.3. 一般クエリ ログ

mysqld での出来事を記録しているのが、一般クエリ ログです。サーバはこのログに、クライアント接続や切断の情報を書き込み、そのときのクライアントからの SQL ステートメントも記録します。一般クエリ ログはクライアント側でのエラーを検討するときに、クライアントが mysqld に何を送ったことによって問題が発生したかを正確に知ることができます。 

mysqld ではステートメントを到着順にクエリ ログに書き込みますが、実行した順番とは異なることがあります。このロギングの順番は、ステートメントを実行した後のクエリがロックがリリースされる前である場合には、バイナリ ログとは対照的です。また、クエリ ログにはすべてのステートメントが入る一方で、バイナリ ログにはデータだけを選択するステーメントは入りません。

MySQL 5.1.6 から、一般クエリ ログを有効化するには、mysqld--log[=file_name] または -l [file_name] で起動するか、あるいは --log-output を使用してログ先を指定します (項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 を参照)。MySQL 5.1.6 前は、一般クエリ ログの出力先は常にファイルです。一般クエリ ログ ファイルを有効化するには、--log[=file_name] または -l [file_name] のオプションを使用します。

--log または -lfile_name 値を指定しない場合、デフォルト名は、host_name.log というデータ ディレクトリのファイル名になります。絶対パスでファイル名を指定しない場合、このファイルはデータ ディレクトリに置かれます。

MySQL 5.1.12 以降、--log または -l を指定する場合、--general-log オプションで最初の一般クエリ ログ状態を指定することも可能です。このオプションで、引数なし、または 値を 0 にすると、ログが無効化します。省略する、または値を 1 とすると、ログが有効化します。--log または-l を指定しない場合、--general-log には何の影響もありません。

general_log および general_log_file のグローバル システム変数で、一般クエリ ログのランタイム制御ができます。general_log を 0 (または OFF) にすると、ログが無効化し、1 (または ON) で有効化します。general_log_file を指定して、ログ ファイルの名前を指定することもできます。ログ ファイルがすでに開いている場合は、それを閉じて、新規ファイルを開けます。

一般クエリ ログを有効化した場合、出力の書き込み先は --log-output オプション、または log_output 環境変数で指定します。ノート: 出力先が NONE である場合、一般ログを有効化していても、出力書き込みはできません。同様に、ログ出力先の値に FILE がない場合は、ログ効果はありません。

サーバの再起動やログのフラッシュでは、一般クエリ ログの新規ファイルを生成しません。フラッシュはファイルを閉じて、それを再び開けるだけです。Unix では、ファイル名を変更して、次のコマンドを使用して、新規ファイルを作成できます。

shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> cp host_name-old.log backup-directory
shell> rm host_name-old.log

Windows では、サーバがログ ファイルを使用している間は、ログ ファイルの名前変更はできません。まずサーバを停止してから、ファイルの名前を変更し、そして、サーバを再起動してから新規のログ ファイルを作成します。

MySQL 5.1.12 から、ランタイムで一般クエリ ログを無効化できるようになりました。

SET GLOBAL general_log = 'OFF';

ログを無効化した状態で、コマンドラインなどを使用して、ログ ファイルの名前を外部的に変更します。そして、ログを再び有効化します。

SET GLOBAL general_log = 'ON';

このやり方は、どのプラットフォームでも使用でき、サーバの再起動は不要です。

4.11.4. バイナリ ログ

バイナリ ログの内容には更新データのステートメントがあり、レコードに一致しない場合の DELETE などで更新済みのステートメントがあります。ステートメントは、変更の内容を説明する 「イベント」 として保存の対象になります。さらに、クエリの更新に要した時間に関する情報も、バイナリ ログの内容です。

注意:バイナリ ログは、更新ログの代わりになるものです。更新ログは MySQL 5.0 以降では利用できません。バイナリ ログには、更新ログで利用可能だった情報がすべて、より効率的かつトランザクション セーフな内容になっています。トランザクションを行うときは、 MySQL バイナリ ログをバックアックに使用します。更新ログを使用しません。

バイナリ ログの内容は、データ変更に関数ステートメントを含みません。そのため、問題があるクエリの識別などで、すべてのステートメントが必要な場合は、一般クエリ ログを使用します。詳細は 項4.11.3. 「一般クエリ ログ」 を参照してください。

バイナリ ログの主要目的は、リストア作業中にできるだけデータベースの更新を行う、ということです。バイナリ ログにはバックアップ後のすべての更新情報が入ることになるため、スレーブ サーバに送るステートメントのマスタ記録として、レプリケーションで使用します。詳細は 章?5. レプリケーション を参照してください。

MySQL Enterprise バイナリ ログで DDL イベントの大部分をトラックに使用することが可能です。扱いには注意が必要です。 MySQL Network Monitoring and Advisory Service では、バイナリ ログ分析に関する情報を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

バイナリ ログを有効化したサーバを実行すると、パフォーマンスが 1% ほど遅れます。しかし、リストア作業が必要になった場合のバイナリ ログの有用性、レプリケーション セットアップでの利便性を考慮すると、1% の遅れは許容できるものとします。

--log-bin[=base_name] オプションで起動すると、mysqldで、データ更新に関わる SQL ステートメントのすべてをログ ファイルに書き込みます。base_name の値を指定しない場合、デフォルト名は、-bin を元にするホスト マシンの名前になります。ベース名を指定するときに、絶対パスを使用しない場合は、サーバでデータ ディレクトリにファイルを作成します。できるだけ、ベース名は指定することをお勧めします。その理由に関しては 項B.1.8.1. 「Open Issues in MySQL」 を参照してください。

--log-bin=base_name.extension など、ログ名に拡張子を付ける場合は、その拡張子はサイレントで削除、無視の対象になります。

mysqld ではバイナリ ログのベース名で数値の拡張子を付加します。この数値はサーバで新規ログ ファイルを作成する度に増加し、ファイルの番号が連続する形になります。サーバは起動、そしてログ フラッシュ毎に、新規のバイナリ ログ ファイルを作成します。さらにサーバは現行のログ サイズが max_binlog_size に到達すると、自動的に新規のバイナリ ログ ファイルを作成します。大きなトランザクションがあると、バイナリ ログ ファイルの max_binlog_size を超えることになるため、1 つのトランザクションで最大値を使い切らないようにする必要があります。

使用しているバイナリ ログ ファイルの追跡を行うために、mysqld で、使用があったバイナリ ログ ファイルのすべての名前を含めた、バイナリ ログ インデックスを作成します。デフォルトではバイナリ ログ ファイルと同じベース名で、'.index' という拡張子がつきます。バイナリ ログ インデックス ファイルの名前は、--log-bin-index[=file_name] オプションを使用して変更できます。mysqld が作業中の場合は、このファイルを手動で変更することはしないでください。mysqld が混乱する原因になります。

バイナリ ログ ファイルとインデックス ファイルへの書き込みは、MyISAM テーブルへの書き込みと同じ方法で処理します。項B.1.4.3. 「How MySQL Handles a Full Disk」 を参照してください。

RESET MASTER ステートメントでバイナリ ログ ファイルをすべて削除する場合、または PURGE MASTER LOGS でそれらをサブセットする場合は、項12.5.5.5. 「RESET 構文」 および 項12.6.1. 「マスタ サーバをコントロールする SQL ステートメント」 を参照してください。

バイナリ ログは、バックアップでリカバリ作業を行うときに影響があることから、いくつかの制限があります。詳細は 項5.4.1. 「レプリケーション機能と既知問題」 を参照してください。

トリガや記憶したルーチンに関するバイナリーロギングは、項17.4. 「ストアドルーチンとトリガのバイナリログ」 を参照してください。

次に示すオプションを mysqld で使用して、何をどうバイナリ ログに記録するかを指定します。後続の説明も参考にしてください。

レプリケーションでは、ここで説明するオプションは、マスタからスレーブに送るステートメントに影響します。また、マスタからのステートメントを受けたスレーブが、そのうちの何を実行して、何を無視するかを制御するオプションもあります。その詳細は 項5.1.3. 「レプリケーションのオプションと変数」 を参照してください。

  • --binlog-do-db=db_name

    db_name などデフォルトのデータベースに関わる更新のバイナリ ロギングを制限する。(データベースは USE で選択可能。) 明示的な指定がない限り、デフォルト以外のデータベースは無視の対象。このオプションを使用するときは、デフォルトのデータベースだけが更新の対象であることを確認すること。

    これには、例外があり、CREATE DATABASEALTER DATABASEDROP DATABASE などのステートメントを使用する場合は、この限りではない。サーバがそのステートメントで指定するデータベース (デフォルトのデータベース以外) によって、ステートメントをログするかどうかを判断する。

    期待通りにならない可能性がある例として、サーバを binlog-do-db=sales で起動した場合に、USE prices; UPDATE sales.january SET amount=amount+1000; を実行すると、このステートメントはバイナリ ログへの書き込み対象ではない

    複数のデータベースをログするには、複数のオプションを使用のこと。それぞれのデータベースにそれぞれのオプションを使用する。

  • --binlog-ignore-db=db_name

    db_name などデフォルトのデータベースに関わる更新のバイナリ ロギングを優先する。(データベースは USE で選択可能。) このオプションを使用するときは、デフォルトのデータベースだけが更新の対象であることを確認すること。

    --binlog-do-db 同様に、これにも例外があり、CREATE DATABASEALTER DATABASEDROP DATABASE などのステートメントを使用する場合は、この限りではない。サーバがそのステートメントで指定するデータベース (デフォルトのデータベース以外) によって、ステートメントをログするかどうかを判断する。

    期待通りにならない可能性がある例として、サーバを binlog-ignore-db=sales で起動した場合に、USE prices; UPDATE sales.january SET amount=amount+1000; を実行すると、このステートメントはバイナリ ログへの書き込み対象になる

    複数のデータベースを無視するには、複数のオプションを使用のこと。それぞれのデータベースにそれぞれのオプションを使用する。

サーバはバイナリ ログへの更新の処理の仕方 (ログか無視か) に関するオプションを、次に示すルールに従って評価します。前述の通り、CREATE DATABASEALTER DATABASEDROP DATABASE のステートメントは例外とします。データベースに対する 作成、変更、ドロップ は、次のルールに従って辿り着きます。

  1. --binlog-do-db または --binlog-ignore-db ルールがあるかどうか。

    • No: バイナリ ログにステートメントを書き込み、終了。

    • Yes: 次のステップへ進む。

  2. デフォルトのデータベース、USE で選択しているデータベースがあるかどうか。(--binlog-do-db--binlog-ignore-db、またはその両方があるため。)

    • No: ステートメントを書き込まず、終了。

    • Yes: 次のステップへ進む。

  3. (デフォルトのデータベースがあるので) --binlog-do-db ルールがあるかどうか。

    • Yes: デフォルトのデータベースは、--binlog-do-db ルールの適用を受けるかどうか。

      • Yes: ステートメントを書き込み、終了。

      • No: ステートメントを書き込まず、終了。

    • No: 次のステップへ進む。

  4. (--binlog-ignore-db ルールがあるため、) --binlog-ignore-db ルールの適用を受けるかどうか。

    • Yes: ステートメントを書き込まず、終了。

    • No: ステートメントを書き込み、終了。

たとえば、--binlog-do-db=sales だけのオプションで実行していると、スレーブは sales とは異なるデータベースのステートメントはバイナリ ログに書き込みません。つまり、--binlog-do-db オプションは、「他のデータベースを無視する」 という働きがあります。

レプリケーションでは、バイナリ ログ ファイルをスレーブで必要としないと確認できるまでは削除しないでください。たとえば、スレーブが 3 日以上遅れることは有り得ない場合、一日に一度、mysqladmin flush-logs をマスタで実行し、3 日以上経過したログを削除します。ファイルは手動で削除することもできますが、PURGE MASTER LOGS の使用をお勧めします。これは、バイナリ ログ インデックス ファイルの更新を安全に行えます。(日の引数使用。) 詳細は、項12.6.1. 「マスタ サーバをコントロールする SQL ステートメント」 を参照してください。

SUPER 権限があるクライアントは、SET SQL_LOG_BIN=0 ステートメントを使用して独自にステートメントのバイナリ ログを無効化できます。詳細は 項12.5.3. 「SET 構文」 を参照してください。

mysqlbinlog ユーティリティを使用して、バイナリ ログ ファイルの内容を表示できます。これは、ログ内のステートメントを再処理するときに活用できます。たとえば、次のように、バイナリ ログから MySQL サーバを更新できます。

shell> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog ユーティリティと、その使用方法については 項7.10. 「mysqlbinlog ? バイナリログファイルを処理するためのユーティリティ」 を参照してください。バイナリ ログ ファイルとリレーログ ファイルは同じ形式で書き込みを行うため、mysqlbinlog をリレー ログ ファイルでも使用できます。

バイナリ ロギングはステートメントの完了 (クエリの完了) とともに実行となりますが、その前にロックのリリース、またはコミットを行います。そのため、ログの記録は実行順になります。

非トランザクションの更新は、実行とともに、バイナリ ログへの保存となります。コミットなしのトランザクション内では、InnoDB テーブルなど、トランザクションのテーブルに変更を与える UPDATEDELETEINSERT などの更新は、サーバからの COMMIT ステートメントを受けるまでは、キャッシュでの保管になります。その時点で、COMMIT 実行前に mysqld でトランザクションの内容をバイナリ ログに書き込みます。トランザクションを扱うスレッドが開始すると、binlog_cache_size というバッファから、ステートメントのバッファにアロケートします。ステートメントがそのバッファより大きい場合は、スレッドがそのトランザクションを保管する一時テーブルを開きます。スレッドが終了すると、テンポラリ テーブルは削除になります。

非トランザクションのテーブルへの変更は、ロール バックが利きません。非トランザクション テーブルへの変更を含むロール バックがあるトランザクションの場合は、トランザクション全体が ROLLBACK ステートメントでのログになり、そのテーブルへの変更の複製を確実に行い (請け負い)ます。

Binlog_cache_use ステータス変数は、(テンポラリファイルとともに) このバッファを使用したトランザクションの数を表示します。Binlog_cache_disk_use ステータス変数はそのトランザクション内で一時テーブルを使用する必要があった回数を表示します。この 2 つの変数は、binlog_cache_size の調整に使用して、一時ファイルの使用を避けるために十分な値を設定します。

max_binlog_cache_size システム変数は、デフォルトで 4 GB (最大値) としていますが、複数のステートメントのトランザクションのキャッシュを行うために、合計サイズを制限することができます。トランザクションがこのバイトより大きい場合はロール バックします。最大値は 4096 です。

バイナリ ログでは、並列のインサートを、CREATE ... SELECT または INSERT ... SELECT ステートメントの通常インサートと置き換えます。これは、たとえば、バックアップ作業中にログを適用して、テーブルの完全コピーを再生できるようにする作用です。

ノート: 古いバージョンの MySQLと MySQL 5.1 とでは、バイナリ ログの形式が異なります。これはレプリケーション効果を改善した結果です。詳細は 項5.4.2. 「MySQL バージョン間のレプリケーション互換性」 を参照してください。

デフォルトのバイナリ ログでは、ディクスへのそれぞれの書き込みは非同期です。そのため、MySQL サーバに限らず、オペレーティング システムまたはマシンがクラッシュすると、バイナリ ログの最後のステートメントを失う可能性があります。これを防ぐには、バイナリ ログへのそれぞれの書き込み N をディスクで同期します。それには、sync_binlog システム変数を使用します。(項4.2.3. 「システム変数」 を参照のこと。) sync_binlog での最も安全な値は 1 ですが、これは最も遅くなる値です。sync_binlog を 1 で設定しても、クラッシュの場合によってテーブルとバイナリ ログの内容が異なる可能性があります。たとえば、InnoDB テーブルに対して、COMMIT ステートメントを MySQL サーバで処理した場合、トランザクション全体をバイナリ ログに書き込むことになり、そのトランザクションを InnoDB にコミットすることになります。この 2 つの動作を処理している最中にサーバがクラッシュすると、このトランザクションは起動時の InnoDB にロール バックしますが、バイナリ ログでは存在している、ということになります。この問題は --innodb-safe-binlog オプションで解決できます。このオプションは、InnoDB テーブルとバイナリ ログの内容に整合性を持たせます。(ノート: MySQL 5.0 以降、--innodb-safe-binlog は、XA トランザクション サポートの導入とともに、廃止になりました。)

このオプションでさらに安全性を高めるには、MySQL サーバを、トランザクション毎にバイナリ ログと InnoDB ログを同期してディスクに送るように設定する必要があります。InnoDB ログはデフォルトで同期化しているため、バイナリ ログには sync_binlog=1 を使用して同期化します。このオプションの効果としては、クラッシュ後に再起動したときに、ロール バックしたトランザクションに対して、MySQL がバイナリ ログから InnoDB トランザクションのロール バック返しを行います。これにより、バイナリ ログが InnoDB テーブルのデータと完全に一致します。そして、スレーブはマスタと同期化したままであるため、ロール バックしたステートメントを受けることはありません。

(ノートとして、--innodb-safe-binlog オプションは、MySQL サーバが InnoDB 以外のストレージ エンジンを更新するときにも使用できます。) InnoDB のクラッシュ リカバリでは、InnoDB テーブルに影響があるステートメントとトランザクションだけを、バイナリ ログから削除します。MySQL サーバがクラッシュ リカバリ中に、バイナリ ログが通常より短いと判断する場合には、InnoDB のトランザクションの中から、成功していないコミットが 1 つ以上あることを示します。つまり、サーバは、The binary log <name> is shorter than its expected size というエラー メッセージを出力します。これは、sync_binlog=1 と指定し、ディスク/ファイル システムが実際に同期していれば、発生しません。もし、このエラー メッセージがでり場合には、このバイナリ ログは未修正のままであるため、レプリケーションを行うときには、マスタ データのスナップショットを最初からやり直す必要が出てきます。

4.11.5. スロー クエリ ログ

スロー クエリ ログの内容は、long_query_time 秒より実行に時間がかかる SQL ステートメントすべてが入ります。最初のテーブル ロックを取得するまでの時間は、実行時間としてはカウントしていません。すべてのステートメントを実行し、すべてのロックをリリースした後に、mysqld で、ステートメントをスロー クエリ ログとして書き込むため、ログ順は実行順とは異なることがあります。最低限値は 1 で、long_query_time のデフォルト値 (最大値) は 10です。

MySQL 5.1.6 以降、スロー クエリ ログを有効化するには、mysqld--log-slow-queries[=file_name] オプションで起動します。必要に応じて、--log-output オプションを使用して、ログの出力先を指定します。(項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 を参照のこと。) MySQL 5.1.6 より前は、スロー クエリ ログの出力先はファイルです。スロー クエリ ログ ファイルを有効化するには、--log-slow-queries[=file_name] オプションを使用します。

--log-slow-queriesfile_name 値を指定しない場合、デフォルト名は、host_name-slow.log というデータ ディレクトリのファイル名になります。絶対パスでファイル名を指定しない場合、このファイルはデータ ディレクトリに置かれます。

MySQL 5.1.12 以降、--log-slow-queries を指定する場合、--slow-query-log オプションで最初のスロー クエリ ログ状態を指定することも可能です。このオプションで、引数なし、または 値を 0 にすると、ログが無効化します。省略する、または値を 1 とすると、ログが有効化します。--log--slow-queries を指定しない場合、--slow-query-log には何の影響もありません。

slow_query_log および slow_query_log_file のグローバル システム変数で、スロー クエリ ログのランタイム制御ができます。slow_query_log を 0 (または OFF) にすると、ログが無効化し、1 (または ON) で有効化します。general_log_file を指定して、ログ ファイルの名前を指定することもできます。ログ ファイルがすでに開いている場合は、それを閉じて、新規ファイルを開けます。

スロー クエリ ログを有効化した場合、出力の書き込み先は --log-output オプション、または log_output 環境変数で指定します。ノート: 出力先が NONE である場合、スロー ログを有効化していても、出力書き込みはできません。同様に、ログ出力先の値に FILE がない場合は、ログ効果はありません。

スロー クエリ ログには、実行に時間がかかるクエリが入るため、最適化の対象になります。しかし、時間がかかるスロー クエリ ログの検査は手間がかかります。ここで、mysqldumpslow コマンドを使用してスロー クエリ ログを処理することで、そのクエリをログに概括表示します。mysqldumpslow --help を使用して、このコマンドに関するサポートを探してください。

MySQL 5.1 では、インデックスを使用しないクエリは、--log-queries-not-using-indexes オプションで指定すると、スロー クエリ ログで記録するようになります。詳細は 項4.2.2. 「コマンド オプション」 を参照してください。

MySQL Enterprise 過剰なテーブル スキャンはインデックスの最適化に悪影響を与える、またはインデックスを損失する原因になります。MySQL Network Monitoring and Advisory Service では、専門家とともにインデックスに関する事前対策、解決策を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

MySQL 5.1 では、スロー クエリ ログに対して、--log-slow-admin-statements というサーバ オプションで、OPTIMIZE TABLEANALYZE TABLEALTER TABLE など、時間がかかる管理ステートメントのロギング要求を有効化します。

クエリ キャッシュで扱うクエリは、スロー クエリ ログには付加しません。テーブルのレコードがない、または 1 つだけであるときは、インデックスで管理する必要がないため、これもスロー クエリ ログには入りません。

4.11.6. ログ ファイルの保守

MySQL Server は、様々なやりとりを把握できるように、様々なログ ファイルを数多く作成しています。(項4.11. 「MySQL サーバ ログ」 を参照のこと。) しかし、ディクス スペースを空けるために、これらのファイルは定期的にクリーンアップすることが必要です。

MySQL でロギングを有効化しているときは、定期的にファイルのバックアップを取り、古いファイルは削除するなどして、時には MySQL ロギング を新しいファイルで行うことも検討してください。詳細は 項4.9.1. 「データベースのバックアップ」 を参照してください。

Linux (Red Hat) では、mysql-log-rotate スクリプトを使用して、古いログ ファイルの処理を自動的に行うことができます。RPM 配布から MySQL をインストールすると、このスクリプトを自動的にインストールしています。注意: レプリケーションにバイナリ ログを使用している場合は、このスクリプトの扱いには注意が必要です。

他のシステムでは、ログファイルを処理するための短いスクリプトを自分でインストールする必要があります。このスクリプトは、cron などで開始します。

MySQL に新しいログ ファイルの使用を強制するには、mysqladmin flush-logs または mysqladmin refresh を使用するか、SQL コマンド FLUSH LOGS を使用します。詳細は、項12.5.5.2. 「FLUSH 構文」 および 項7.9. 「mysqladmin ? MySQL サーバの管理を行うクライアント」 を参照してください。

ログのフラッシュ操作は次のことを行います。

  • ログ ファイルへの一般クエリ ロギング (--log)、またはスロー クエリ ロギング (--log-slow-queries) を有効化した場合、サーバが一般クエリ ログ ファイルまたはスロー クエリ ログ ファイルを閉じ、再開する。

  • バイナリ ロギング (--log-bin) を使用している場合、サーバは現行のログ ファイルを閉じ、シーケンス番号で新しいログ ファイルを開く。

  • --log-error オプションでエラー ログ ファイル名を指定している場合、-old をサフィックスとするエラー ログ ファイルの名前になり、新しいエラー エラー ログ ファイルを作成する。

ログをフラッシュすると、サーバで新しいバイナリ ログ ファイルを作成します。しかし、これは一般ログとスロー ログを閉じて、また再開するだけに過ぎません。Unix 環境で新しいファイルを作成するようにするには、フラッシュする前に現行ログの名前を変更します。そうすると、フラッシュするときに、サーバがオリジナルの名前で新しいログを開きます。たとえば、一般クエリ ログを mysql.log とし、スロークエリのログを mysql-slow.log とした場合には、次のようにコマンドをつなげます。

shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mv mysql-slow.log mysql-slow.old
shell> mysqladmin flush-logs

この時点で、mysql.oldmysql-slow.log のバックアップができるので、ディスクから削除することができます。

Windows では、サーバがログ ファイルを使用している間は、ログ ファイルの名前変更はできません。まずサーバを停止してから、ファイルの名前を変更し、そして、サーバを再起動してから新しいログ ファイルを作成します。

MySQL 5.1.12 から、ランタイムで一般クエリ ログとスロー クエリ ログを無効化できるようになりました。

SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';

ログを無効化した状態で、コマンドラインなどを使用して、ログ ファイルの名前を外部的に変更します。そして、ログを再び有効化します。

SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';

このやり方は、どのプラットフォームでも使用でき、サーバの再起動は不要です。

4.12. 同じマシン上での複数 MySQL サーバの実行

場合によっては、複数の mysqld サーバを同一のマシンで起動することがあります。たとえば、既存の稼働環境のままにして、新しい MySQL リリースをテストしたい場合が考えられます。また、ユーザごとに異なる mysqld サーバへのアクセス権を与える場合などもあります(顧客ごとに独立した MySQL インストールを提供するインターネット サービス プロバイダなど)。

単一のマシン上で複数のサーバを実行するには、いくつかのパラメータでサーバ固有の値を設定する必要があります。これらはコマンドラインまたはオプション設定ファイルで設定します。プログラム オプションに関しては、項3.3. 「プログラム・オプションの指定」 を参照してください。

少なくとも、次のオプションをサーバごとに変えます。

  • --port=port_num

    --port は、TCP/IP 接続のポート番号を制御する。

  • --socket=path

    --socket で、Unix のソケット ファイル パス、または Windows の名前付きパイプを制御する。Windows では、名前付きパイプ接続をサポートしているサーバに対して、独特のパイプ名を指定する必要がある。

  • --shared-memory-base-name=name

    Windows のみで使用可能。Windows で使用する共有メモリ名を指し、共有メモリ経由でクライアントの接続を許可する。共有メモリ接続をサポートするサーバに対して、共有メモリに独特な名前を指定する必要がある。

  • --pid-file=file_name

    Unix のみで使用可能。サーバがプロセス ID を書き込むファイルのパス名を指定する。

次のログ ファイル オプションを使用する場合は、それぞれのサーバに対して異なる値を設定する。

  • --log=file_name

  • --log-bin=file_name

  • --log-update=file_name

  • --log-error=file_name

項4.11.6. 「ログ ファイルの保守」で、ログ ファイルのオプションについて参照してください。

パフォーマンスを高めるには、次のオプションをサーバに別々に指定して、物理ディスク間の負荷を分けます。

  • --tmpdir=path

複数のテンポラリ ディレクトリを置くと、どの MySQL サーバにどの一時ファイルが属するのかわかりやすなるため、お勧めです。

データ ディレクトリについても、それぞれのサーバで異なるディレクトリを使用するようにします。これは --datadir=path オプションで指定します。

警告:2 つのサーバから同じデータベースのデータを更新しないでください。使用しているオペレーティング システムで障害からの保護ができるシステム ロックをサポートしていない場合、予期しない事態が発生する可能性があります。また、複数のサーバが同じデータ ディレクトリを使用し、ログを有効化している場合、適切なオプションを使用して、それぞれのサーバに異なるログ ファイル名を指定する必要があります。そうしないと、サーバ同士で同じファイルにログします。このセットアップは、MyISAM まはた MERGE テーブルでのみ機能します。他のストレージ エンジンでは使用できません。

サーバ間でのデータ ディレクトリ共有に関するこの警告は、NFS 環境にも当てはまります。NFS 環境で複数の MySQL サーバに同じデータ ディレクトリへのアクセスを認めることは しないでください

  • 重要な問題として、NFS は速度のボトルネック。NFS にはそのような使用目的はない。

  • 2 つ以上のサーバが互いに干渉しないようにすることが困難。通常、NFS ファイルロックは lockd デーモンで処理するが、現在のところ、どのような状況でも 100% の信頼性でロックを実行できるプラットフォームは存在しない。

NFS で複数のサーバにデータ ディレクトリを共有することは賢明ではありません。 また、複数の CPU を持つ 1 台のコンピュータを用意し、スレッドを効率的に処理するオペレーティング システムを使用してください。

複数の MySQL インストールを異なる場所にする場合、--basedir=path オプションを使用して、それぞれのサーバに対してベース ディレクトリを指定し、それぞれのサーバがお互いに別のデータ ディレクトリ、ログ ファイル、および PID ファイルを使用するようにします(これらの値のデフォルトは、ベース ディレクトリと相対的に決定します)。そして、他にも指定する必要があるオプションとして、--socket--port があります。たとえば、バイナリ配布の .tar ファイルを使用して MySQL の複数のバージョンをインストールするとします。これらを別々の場所にインストールすれば、対応するベース ディレクトリ下で ./bin/mysqld_safe コマンドを使用して、インストールしたサーバを別々に起動できます。 mysqld_safe が、mysqld に渡す適切な --basedir オプションを特定するため、--socket オプションと --port オプションを mysqld_safe に設定するだけで済みます。

次のセクションで説明するように、環境変数の設定または適切なコマンドライン オプションの指定で、追加サーバを起動することが可能です。ただし、より永続的に複数のサーバを実行する必要がある場合には、オプション設定ファイルを使用して、それぞれサーバ固有のオプション値を指定する方法が便利です。これには、--defaults-file オプションを活用します。

4.12.1. Windows で複数サーバの実行

適切なパラメータで、コマンドラインからサーバを手動で起動すると、Windows 上で複数のサーバを実行できます。Windows NT ベースのシステムでは、複数のサーバを Windows サービスとしてインストールし、Windows サービスとして実行する方法もあります。コマンドラインから、またはサービスとして MySQL サーバを実行する方法については、項2.3. 「Windows に MySQL をインストールする」 を参照してください。このセクションでは、データ ディレクトリなど、スタートアップ オプション値をサーバごとに固有設定してサーバを起動する方法について説明します。オプションについては、項4.12. 「同じマシン上での複数 MySQL サーバの実行」 を参照してください。

4.12.1.1. コマンドラインで複数の Windows サーバの起動

コマンドラインから複数のサーバを手動で起動するには、コマンドラインまたはオプション ファイルで必要なオプションを指定します。オプション ファイルでオプションを設定する方は簡単ですが、それぞれのサーバに固有のオプション セットを確実に設定するには注意が必要です。これを行うには、それぞれのサーバにオプション ファイルを作成し、サーバ起動時に --defaults-file を使用して、サーバにファイル名を指定します。

たとえば、mysqld を、C:\mydata1 というデータディレクトリ、ポート 3307 で実行し、一方で、mysqld-debug を、C:\mydata2 というデータディレクトリ、ポート 3308 で実行するとします。実行する前に、それぞれのディレクトリがあることを確認し、それぞれに権限テーブルを含む mysql データベースのコピーがあることも確認します。それから、2 つのオプション ファイルを作成します。たとえば、次のような C:\my-opts1.cnf という名前のファイルを作成します。

[mysqld]
datadir = C:/mydata1
port = 3307

そして、C:\my-opts2.cnf という名前の 2 番目のファイルを、次のように作成します。

[mysqld]
datadir = C:/mydata2
port = 3308

それぞれのオプション ファイルで、それぞれのサーバを起動します。

C:\> C:\mysql\bin\mysqld --defaults-file=C:\my-opts1.cnf
C:\> C:\mysql\bin\mysqld-debug --defaults-file=C:\my-opts2.cnf

Windows NT では、サーバがフォアグラウンドで起動するため、2 つのコマンドを別々ののコンソール ウィンドウで実行します。

サーバをシャットダウンするには、該当するポート番号に接続する必要があります。

C:\> C:\mysql\bin\mysqladmin --port=3307 shutdown
C:\> C:\mysql\bin\mysqladmin --port=3308 shutdown

この例示のように設定したサーバは、クライアントに対して TCP/IP 接続を許可します。Windows の名前付きパイプ接続も可能にするには、mysqld-nt サーバを使用し、名前付きパイプを有効にするオプションでその名前を指定します(名前付きパイプ接続をサポートするサーバは、それぞれ固有のパイプ名を使用します)。たとえば、C:\my-opts1.cnf ファイルを次のように修正します。

[mysqld]
datadir = C:/mydata1
port = 3307
enable-named-pipe
socket = mypipe1

そして、サーバを次のように起動します。

C:\> C:\mysql\bin\mysqld-nt --defaults-file=C:\my-opts1.cnf

2 つ目のサーバで使用する C:\my-opts2.cnf も同様に修正します。

共有メモリ接続をサポートするときにも、同様の手順で設定します。--shared-memory オプションで接続を有効化し、--shared-memory-base-name オプションで固有の共有メモリ名をそれぞれのサーバに指定します。

4.12.1.2. 複数の Windows サーバをサービスとして起動

Windows NT ベースのシステムでは、MySQL サーバを Windows サービスとして実行します。単一の MySQL サービスのインストール、制御、および削除の手順については、項2.3.11. 「Windows のサービスとして MySQL を起動する」 を参照してください。

複数のサーバをサービスとしてインストールことも可能です。その場合、それぞれのサーバで異なるサービス名を使用します。また、サーバごとに一意である必要があるため、その他のパラメータにも注意が必要です。

次の手順は、CC:\mysql-5.0.19 および C:\mysql-5.1.15-beta と、2 つの異なる MySQL バージョンをインストールした mysqld-nt サーバを実行する場合を想定しています。たとえば、本稼働サーバとして 5.0.19 を実行しているときに、アップグレード前に 5.1.15-beta をテストする場合などが該当します。

--install または --install-manual オプションで MySQL サービスをインストールする場合には、次の原則があります。

  • サービス名を指定しない場合、サーバは MySQL のデフォルト サービス名を使用し、標準オプション ファイルの [mysqld] グループからオプションを読み取る。

  • --install オプションの後でサービス名を指定すると、サーバは [mysqld] オプション グループを無視し、サービスと同じ名前のグループからオプションを読み取る。サーバは、標準オプション ファイルからオプションを読み取る。

  • サービス名の後で --defaults-file オプションを指定すると、サーバは標準オプション設定ファイルを無視し、指定ファイルの [mysqld] グループからのみオプションを読み取る。

注意:MySQL 4.0.17 より前では、デフォルトのサービス名 ((MySQL)) でインストールしたサーバ、または mysqld というサービス名で明示的にインストールしたサーバでだけ、標準オプション設定ファイルの [mysqld] グループを読み込みが可能でした。4.0.17 以降は、インストールしたサービス名を問わず、標準オプション ファイルを読み込めるすべてのサーバで [mysqld] グループを読みます。これにより、すべての MySQL サービスで使用する必要があるオプションに [mysqld] グループを使用でき、それぞれのサービスでインストールしたサーバで、そのサービス名を元に名付けたオプション グループを使用できるようになりました。

この情報を元に、複数のサービスを様々な方法でセットアップできます。次の手順では、その例を示します。これらを試行するときは、シャットダウンし、既存の MySQL サービスを別の場所などに移動/削除してください。

  • アプローチ 1:オプションをすべてのサービスに対して 1 つの標準オプション ファイルで指定し、それぞれのサーバに対して別々のサービス名を与えます。 MySQL 5.0.19 には、mysqld1 というサービス名を mysqld-nt で、MySQL 5.1.15-beta では mysqld2 というサービス名を mysqld-nt で、それぞれ実行するとした場合、 MySQL 5.0.19 には [mysqld1] グループを、MySQL 5.1.15-beta には [mysqld2] グループを使用します。たとえば、C:\my.cnf を次のようにセットアップします。

    # options for mysqld1 service
    [mysqld1]
    basedir = C:/mysql-5.0.19
    port = 3307
    enable-named-pipe
    socket = mypipe1
    
    # options for mysqld2 service
    [mysqld2]
    basedir = C:/mysql-5.1.15-beta
    port = 3308
    enable-named-pipe
    socket = mypipe2
    

    それぞれのサービスを次のようにインストールします。フル パスを使用して、Windows で正確な実行プログラムをそれぞれのサービスで登録することを確認してください。

    C:\> C:\mysql-5.0.19\bin\mysqld-nt --install mysqld1
    C:\> C:\mysql-5.1.15-beta\bin\mysqld-nt --install mysqld2
    

    サービスを起動するには、サービス マネージャを使用するか、または該当するサービス名で NET START を使用します。

    C:\> NET START mysqld1
    C:\> NET START mysqld2
    

    サービスを停止するには、サービス マネージャを使用するか、または該当するサービス名で NET STOP を使用します。

    C:\> NET STOP mysqld1
    C:\> NET STOP mysqld2
    
  • アプローチ 2:別々のファイルでそれぞれのサーバに対して、オプションを指定します。サービスをインストールするときは、--defaults-file を使用して、それぞれのサーバでどのファイルを使用するかを指します。この場合、それぞれのファイルで [mysqld] を使用して、オプションをリストします。

    このアプローチで、MySQL 5.0.19 の mysqld-nt に対するオプションを指定し、C:\my-opts1.cnf というファイルを次のように作成します。

    [mysqld]
    basedir = C:/mysql-5.0.19
    port = 3307
    enable-named-pipe
    socket = mypipe1
    

    MySQL 5.1.15-beta の mysqld-nt に対しては、C:\my-opts2.cnf というファイルを次のように作成します。

    [mysqld]
    basedir = C:/mysql-5.1.15-beta
    port = 3308
    enable-named-pipe
    socket = mypipe2
    

    サービスを次のようにインストールします。(それぞれのコマンドを一行で入力してください。)

    C:\> C:\mysql-5.0.19\bin\mysqld-nt --install mysqld1
               --defaults-file=C:\my-opts1.cnf
    C:\> C:\mysql-5.1.15-beta\bin\mysqld-nt --install mysqld2
               --defaults-file=C:\my-opts2.cnf
    

    MySQL サーバをサービスとしてインストールするには、--defaults-file オプションを使用します。サービス名でそのオプションを優先化します。

    サービスをインストール後、それぞれを前述の例示と同じ方法で、起動と停止を行います。

複数のサービスを削除するには、mysqld --remove をそれぞれに使用し、後続の --remove オプションでサービス名を指定します。デフォルトのサービス名 (MySQL) を使用している場合には、この指定は省略可能です。

4.12.2. Unix で複数サーバの実行

Unix で複数のサーバを実行する最も簡単な方法は、異なる TCP/IP ポートと Unix ソケット ファイルでサーバをコンパイルすることです。これは、それぞれが異なるネットワークのインターフェースとしてリストします。それぞれのインストールに対して、異なるベース ディレクトリにコンパイルすることも、コンパイルしたデータ ディレクトリ、ログ ファイル、PID ファイル場所を、サーバごとに自動的に切り離す結果を生みます。

ここでは、既存の MySQL 5.0.19 サーバをデフォルトの TCP/IP ポート番号 (3306) と Unix ソケットファイル (/tmp/mysql.sock) で設定していると想定します。MySQL 5.1.15-beta サーバの設定で、異なる操作パラメータを持たせるには、configure コマンドを次のように使用します。

shell> ./configure --with-tcp-port=port_number \
             --with-unix-socket-path=file_name \
             --prefix=/usr/local/mysql-5.1.15-beta

ここで、port_numberfile_name は、デフォルトの TCP/IP ポート番号と Unix ソケット ファイルのパスとは異なる必要があります。--prefix 値は、既存の MySQL をインストールしたディレクトリとは異なるディレクトリに指定します。

MySQL サーバに特定のポート番号をリストしている場合は、次のコマンドを使用して、重要な設定可能変数において、ベース ディレクトリおよび Unix ソケット ファイル名を含め、どの操作パラメータをそこで使用しているかを確認します。

shell> mysqladmin --host=host_name --port=port_number variables

このコマンドで表示する情報を元に、追加サーバを設定するときに 使用できない オプション値がどれであるかを確認します。

ノート: localhost をホスト名として指定する場合、mysqladmin は TCP/IP ではなく Unix ソケット ファイルでの接続に初期化します。MySQL 4.1 以降では、使用する接続プロトコルを、--protocol={TCP|SOCKET|PIPE|MEMORY} オプションを使用して指定することができます。

新しい MySQL サーバを、単に異なる Unix ソケット ファイルと TCP/IP ポート番号で起動するためだけにコンパイルする必要はありません。同一のサーバのバイナリを使用して、ランタイムに別々のパラメータ値で、それぞれの起動 (呼び出し) を行うことができます。これを行う 1 つの方法としては、次のように、コマンドライン オプションを使用します。

shell> mysqld_safe --socket=file_name --port=port_number

2 つ目のサーバを起動するには、異なる値を --socket--port のオプションで使用して、--datadir=path オプションを mysqld_safe に渡します。これにより、このサーバは異なるデータ ディレクトリを使用するようになります。

同様の効果を成す別の方法としては、環境変数を使用して、Unix ソケット ファイル名と TCP/IP ポート番号をセットします。

shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> mysql_install_db --user=mysql
shell> mysqld_safe --datadir=/path/to/datadir &

テスト用で 2 番目のサーバを起動するには、この方法が一番早くできます。この手順の利点は、環境変数の設定で、同じシェルから呼び出すクライアント プログラムにも適用できるため、クライアント接続は自動的に 2 番目のサーバになります。

項2.14. 「環境変数」 では、mysqld に反映する環境変数のリストについて説明しています。

自動的なサーバ実行では、ブートしたときに実行する起動スクリプトが次のコマンドが、それぞれのコマンドに該当するオプション ファイルのパスで、それぞれのサーバの対して一度実行します。

shell> mysqld_safe --defaults-file=file_name

それぞれのオプション ファイルには、特定のサーバ固有のオプション値があります。

Unix では、この mysqld_multi スクリプトで複数のサーバを起動することが 1 つの方法といえます。項4.3.3. 「mysqld_multi ? 複数のMySQL サーバ管理」 を参照してください。

4.12.3. 複数サーバ環境でのクライアントプログラムの使用

クライアントにコンパイルしたネットワーク インタフェースとは異なる (以外の) ネットワーク インタフェースを使用している MySQL サーバに、そのクライアントから接続するには、次のいずれかの方法を使用します。

  • CP/IP 経由でリモートホストに接続に、--host=host_name --port=port_number を使用して、TCP/IP 経由でローカル サーバに接続するには、--host=127.0.0.1 --port=port_number を使用して、クライアントを立ち上げる。または Unix ソケット ファイルまたはWindows 名前付きパイプ経由でローカル サーバに接続するには、--host=localhost --socket=file_name を使用する。

  • MySQL 4.1 から、TCP/IP 経由で接続する場合は --protocol=tcp を、Unix ソケットを使用する場合は --protocol=socket を、名前付きパイプを使用する場合は --protocol=pipe を、共有メモリを使用する場合には --protocol=memory を指定して、クライアントを開始する。TCP/IP 接続では、--host オプションと --port オプションを指定することが必要な場合もある。他の接続タイプでは、場合によっては、--socket オプションで、Unix ソケットまたはWindows 名前付きパイプ名を指定したり、--shared-memory-base-name オプションで共有メモリ名を指定することが必要になる。 共有ファイルを使用した接続は Windows だけで可能。

  • Unix では、クライアントを起動する前に、MYSQL_UNIX_PORT 環境変数と MYSQL_TCP_PORT 環境変数を設定して、Unix ソケットおよび TCP/IP ポート番号を指定する。特定のソケットまたはポートを永続的に使用する場合、これらの環境変数を設定するコマンドを .login ファイルに置いて、ログインごとにこれらの環境変数を適用するようにできる。 詳細は 項2.14. 「環境変数」 を参照のこと。

  • オプション ファイルの [client] グループに、デフォルトソケットと TCP/IP ポートを指定する。たとえば、Windows では C:\my.cnf を、Unix ではホームディレクトリの .my.cnf ファイルを使用する。詳細は 項3.3.2. 「オプションファイルの使用」 を参照のこと。

  • C プログラムでは、ポートまたはソケット引数を mysql_real_connect() の呼び出しで指定できる。また、mysql_options() を呼び出して、プログラムにオプション ファイルを読み取らせることもできる。詳細は、項23.2.3. 「C API機能の説明」 を参照のこと。

  • Perl の DBD::mysql モジュールを使用している場合、MySQL オプション ファイルからオプションを読み取ることができる。次に例を示す。

    $dsn = "DBI:mysql:test;mysql_read_default_group=client;"
            . "mysql_read_default_file=/usr/local/mysql/data/my.cnf";
    $dbh = DBI->connect($dsn, $user, $password);
    

    配列照合に関する詳細は 項23.4. 「MySQL Perl API」 を参照してください。

    他のプログラミング インターフェースでも、オプション ファイル読み込みに関する同様の機能を提供していることがあります。

4.13. MySQL クエリ キャッシュ

クエリ キャッシュには、SELECT ステートメントのテキストを、クライアント送信の関連結果を合わせて格納します。後でまったく同じクエリを受け取ると、サーバはそのクエリの解析と実行を繰り返す代わりに、クエリ キャッシュから結果を取り出します。

テーブルの一部を頻繁には変更することがなく、同じクエリを何度も実行するような環境では、クエリ キャッシュが非常に役立ちます。 動的コンテンツを大量に持つ多くの Web サーバでは、このような状況が一般的です。

注意:クエリキャッシュから古いデータが返ることはありません。データ変更があると、クエリ キャッシュに関連するエントリをすべてフラッシュします。

注意:複数の mysqld サーバで 同一のMyISAM テーブルを更新している環境では、クエリ キャッシュは機能しません。

注意:クエリ キャッシュは、サーバ サイドの準備されたステートメント (準備文) には使用できません。サーバ サイドの準備文がある場合には、クエリ キャッシュの条件を満たしません。詳細は 項23.2.4. 「準備されたC APIステートメント。」 を参照してください。

クエリ キャッシュのパフォーマンスに関するデータの一部を次に示します。これらの結果は、2 GB の RAM、64 MB のクエリキャッシュを搭載する Linux Alpha 2 × 500 MHz での MySQL ベンチマークスィートの実行により生成したものです。

  • レコードが 1 つしかないテーブルからレコードを 1 つ選択する場合など、実行しているクエリが単純であるに関わらず、互いに異なることが原因で、クエリをキャッシュすることができないときは、クエリ キャッシュをアクティブにしておくことによるオーバーヘッドは 13% になる。 これは最悪の場合のシナリオとみなすことができる。現実には、クエリはこの例よりもはるかに複雑なため、通常オーバーヘッドはかなり低くなる。

  • レコードが 1 つだけのテーブルでの 1 つのレコードの検索では、238% 迅速化する。これは、キャッシュに格納してるクエリで想定している迅速化の最小値に近い数値である。

クエリ キャッシュのコードを無効にするには、query_cache_size=0 と、設定する。クエリ キャッシュ コードを無効にすると、目立ったオーバーヘッドはなくなる。MySQL をソースから建てている場合、--without-query-cache オプションで configure を呼び出し、クエリ キャッシュをコードから除外できる。

4.13.1. クエリ キャッシュの動作

このセクションは、クエリ キャッシュのメカニズムを説明します。設定方法は、項4.13.3. 「クエリ キャッシュの設定」 を参照してください。

解析前のクエリには、解釈が始まる前にクエリ キャッシュにあるクエリとの照合を行います。そのため、次の 2 つのクエリは、クエリ キャッシュで異なるものである、とみなします。

SELECT * FROM tbl_name
Select * from tbl_name

クエリは、バイト同士など、完全に一致する しない限り、同一とは判断しません。たとえば、クライアントで新しい形式の通信プロトコルを使用している場合や、別のクライアントが使用しているものとは異なるキャラクタセットを使用している場合も、同じものであるはずのクエリが異なるものとして、認識することがあります。

クエリ キャッシュは、解釈が始まる前にクエリ同士を照合することから、次のような種類のクエリはキャッシュの対象になりません。

  • 準備されたステートメント (準備文)

  • クエリが外部クエリのサブクエリである場合

  • Stored プロシージャ、Stored 関数、トリガ、イベントなどのボディ内で実行したクエリ

クエリ結果をキャッシュからフェッチする前に、MySQL で、そのユーザがすてべのデータベースと関連するテーブルにおいて、 SELECT 権限があるかどうかを調べます。権限がない場合は、キャッシュ結果は使用しません。

クエリ結果がキャッシュから返る度に、サーバは Qcache_hits システム変数の値を増加します。Com_select ではありません。詳細は 項4.13.4. 「クエリ キャッシュのステータスと保守」 を参照してください。

テーブルに変更があった場合、そのテーブルからキャッシュしたクエリのすべてが無効になるため、キャッシュからは削除します。変更があったクエリのマップである MERGE テーブルを使用するクエリも削除の対象になります。INSERTUPDATEDELETETRUNCATEALTER TABLEDROP TABLEDROP DATABASE など、様々なステートメントでテーブルは変化します。

InnoDB テーブルを使用するトランザクションでもクエリ キャッシュを使用します。

MySQL 5.1 では、ビューで生成したクエリもキャッシュします。

クエリ キャッシュは、SELECT SQL_CALC_FOUND_ROWS ... のクエリで動作し、後続する SELECT FOUND_ROWS() クエリで返る値を格納します。FOUND_ROWS() は前のクエリがキャッシュからフェッチしていても、正確な値を返します。これは、検索したレコードの数をキャッシュで保管しているためです。SELECT FOUND_ROWS() クエリ自体はキャッシュの対象ではありません。

次のテーブルに示す関数を含む場合は、どのようなクエリでもキャッシュの対象にはなりません。

BENCHMARK()CONNECTION_ID()CURDATE()
CURRENT_DATE()CURRENT_TIME()CURRENT_TIMESTAMP()
CURTIME()DATABASE()ENCRYPT() (パラメータなし)
FOUND_ROWS()GET_LOCK()LAST_INSERT_ID()
LOAD_FILE()MASTER_POS_WAIT()NOW()
RAND()RELEASE_LOCK()SYSDATE()
UNIX_TIMESTAMP() (パラメータなし)USER()?

次の条件がある場合のクエリもキャッシュの対象にはなりません。

  • ユーザ定義関数 (UDF) または格納された関数 (stored functions) を指す場合

  • ユーザ変数を指す場合

  • mysql システム データベースのテーブルを指す場合

  • 次に示す形のものである場合

    SELECT ... IN SHARE MODE
    SELECT ... FOR UPDATE
    SELECT ... INTO OUTFILE ...
    SELECT ... INTO DUMPFILE ...
    SELECT * FROM ... WHERE autoincrement_col IS NULL
    

    最後の例がキャッシュにならない理由は、それが ODBC のワークアラウンド (特別の手段) として、最後のインサート ID 値が存在するため。章?24. MySQL コネクタ の MyODBC セクションを参照のこと。

  • 準備されたステートメントとして発行した場合。プレースホルダを採用していない場合も同様。例として、次のようなクエリはキャッシュにならない。

    char *my_sql_stmt = "SELECT a, b FROM table_c";
    /* ... */
    mysql_stmt_prepare(stmt, my_sql_stmt, strlen(my_sql_stmt));
    

    詳細は 項23.2.4. 「準備されたC APIステートメント。」 を参照してください。

  • TEMPORARY テーブルを使用している場合

  • テーブルを全く使用しない場合。

  • 関連テーブルのすべてに対して、ユーザがカラム レベルの権限を持つ場合。

4.13.2. クエリ キャッシュでの SELECT オプション

SELECT ステートメントで、クエリ キャッシュ関連の 2 つのパラメータを指定することができます。

  • SQL_CACHE

    query_cache_type 環境変数の値が、DEMAND または ON のときは、クエリ結果をキャッシュします。

  • SQL_NO_CACHE

    クエリ結果をキャッシュしません。

例:

SELECT SQL_CACHE id, name FROM customer;
SELECT SQL_NO_CACHE id, name FROM customer;

4.13.3. クエリ キャッシュの設定

have_query_cache というサーバのシステム変数は、クエリ キャッシュの利用可能にします。

mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+

MySQL 標準バイナリを使用しているときは、この値は常に、YES です。クエリ キャッシュを無効化している場合も同様です。

システム変数によっては、クエリ キャッシュのオペレーション制御を行います。mysqld 起動時に、オプション ファイルやコマンドラインで指定できます。クエリ キャッシュのシステム変数名はすべて、query_cache_ という文字で始まります。これに関する簡単な説明を 項4.2.3. 「システム変数」 で参照してください。このセクションでは、設定に関する情報を提供します。

クエリ キャッシュのサイズを設定するには、query_cache_size システム変数を使用します。値を 0 にすると、クエリ キャッシュは無効化します。デフォルトは 0 で設定しています。

注意

Windows Configuration Wizard を使用して、MySQL をインストールまたは設定するときは、利用可能なコンフィギュレーションの種類に合わせて、自動的に query_cache_size の値をデフォルト設定します。Windows Configuration Wizard を使用するときは、場合によって、クエリ キャッシュが有効化します。つまり、ゼロではない値になることがあります。クエリ キャッシュの制御は、query_cache_type 変数で行います。コンフィギュレーションを始めるときには、my.ini ファイルでこの変数の値を確認してください。

query_cache_size の値がゼロではない場合は、ストラクチャのアロケートにおよそ 40 KB を必要とするため、クエリ キャッシュのサイズを最低 40 KB でセットしてください。正確なサイズは、システムのアーキテクチャによります。サイズが小さすぎると、警告がでます。

mysql> SET GLOBAL query_cache_size = 40000;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Warning
   Code: 1282
Message: Query cache failed to set size 39936; ≫
         new query cache size is 0

mysql> SET GLOBAL query_cache_size = 41984;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_size | 41984 |
+------------------+-------+

クエリ キャッシュでクエリ結果を維持するには、サイズを大きく設定してください。

mysql> SET GLOBAL query_cache_size = 1000000;
Query OK, 0 rows affected (0.04 sec)

mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| query_cache_size | 999424 | 
+------------------+--------+
1 row in set (0.00 sec)

query_cache_size は、1024 バイトに近い値のブロックで位置合わせしています。そのため、報告の値は、設定したものとは異なる可能性があります。

クエリ キャッシュのサイズが 0 より大きい場合、query_cache_type 変数がその機能に影響します。この変数は次のような値に設定できます。

  • 0 または OFF という値で、キャッシュを行わない、または キャッシュした結果の読み出しを行わない、という効果になります。

  • 1 または ON という値で、SELECT SQL_NO_CACHE で始まるステートメント以外のキャッシュになります。

  • 2 または DEMAND という値で、SELECT SQL_CACHE で始まるステートメントだけのキャッシュになります。

GLOBAL query_cache_type の値を設定すると、変更後に接続するクライアントに対するクエリ キャッシュの動作を指定できます。SESSION query_cache_type の値を設定すると、それぞれのクライアントで接続時のキャッシュ動作を制御できます。たとえば、クライアントは自分のクエリに対するクエリ キャッシュの使用を無効化します。そのクエリは次のようなものです。

mysql> SET SESSION query_cache_type = OFF;

キャッシュしたそれぞれのクエリ結果の最大サイズの制御は、query_cache_limit 変数で行います。デフォルトは 1 MB です。

クエリをキャッシュする設定である場合、その結果 (クライアントに送信したデータ) を、結果の読み出し中に、クエリ キャッシュに格納します。そのため、データの扱いは、ひとまとめではありません。つまり、クエリ キャッシュで、データをブロックに分割するため、1 つのブロックが埋まれば、次のブロックを埋めることになります。これは、メモリの割り当てに時間がかかるため、クエリ キャッシュではブロックにします。そのときのブロックのサイズを決定するのが、query_cache_min_res_unit 変数です。そして、クエリ実行毎に、ブロックはサイズでトリムすることになるので、メモリを節約できます。サーバで実行するクエリの種類によっては、 query_cache_min_res_unit の値を調整すると効果が高まります。

  • query_cache_min_res_unit のデフォルト値は、4 KB です。大抵の場合、これで十分です。

  • 結果が小さいクエリが多い場合は、フリーのブロックが多く存在することになり、デフォルトのブロック サイズはメモリのフラグメントになります。フラグメントは、メモリ不足を解消するために、キャッシュからクエリを取り除く (削除) 動作を強制的に行います。そのため、query_cache_min_res_unit の値を減らす必要が出てきます。フリー ブロックの数は Qcache_free_blocks を、そして、この動作で強制的に削除の対象になったクエリは Qcache_lowmem_prunes を、それぞれのステータス変数で確認してください。

  • クエリの大部分が大きな結果である場合は、query_cache_min_res_unit で値を増やして、パフォーマンスを改善できます。(Qcache_total_blocks および Qcache_queries_in_cache で、ステータス変数を確認してください。) しかし、値を増やすと、前述のようにメモリ不足の状態になるので、注意が必要です。

MySQL Enterprise クエリ キャッシュをうまく活用できないと、パフォーマンスに支障がでます。MySQL Network Monitoring and Advisory Service では、対応策などを提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

4.13.4. クエリ キャッシュのステータスと保守

次のステートメントを使用して、MySQL サーバでクエリ キャッシュを行っているかどうかを確認できます。

mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+

メモリ不足対策で、クエリ キャッシュのフラグには、FLUSH QUERY CACHE ステートメントを使用します。このステートメントでは、キャッシュからクエリが消えることはありません。

RESET QUERY CACHEステートメントは、クエリ キャッシュからクエリ結果を削除します。FLUSH TABLES ステートメントでも同様のことができます。

クエリ キャッシュのパフォーマンスを監視するには、SHOW STATUS を使用して、キャッシュのステータス変数をみます。

mysql> SHOW STATUS LIKE 'Qcache%';
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| Qcache_free_blocks      | 36     |
| Qcache_free_memory      | 138488 |
| Qcache_hits             | 79570  |
| Qcache_inserts          | 27087  |
| Qcache_lowmem_prunes    | 3114   |
| Qcache_not_cached       | 22989  |
| Qcache_queries_in_cache | 415    |
| Qcache_total_blocks     | 912    |
+-------------------------+--------+

れぞれの変数に関する詳細は、項4.2.5. 「ステータス変数」 を参照してください。

SELECT クエリの合計数は、次の計算式で求めます。

  Com_select
+ Qcache_hits
+ queries with errors found by parser

Com_select 値は次の計算式で求めます。・

  Qcache_inserts
+ Qcache_not_cached
+ queries with errors found during the column-privileges check

クエリ キャッシュでは、変数長さのブロックを使用するため、クエリ キャッシュのメモリ フラグメンテーションは、Qcache_total_blocks および Qcache_free_blocks で確認できます。FLUSH QUERY CACHE 後には、フリーのブロックが 1 つになります。

キャッシュするクエリには、少なくとも 2 つのブロックを必要とします。1 つはクエリ テキスト用で、もう 1 つはクエリ結果用です。さらに、もう 1 つ、テーブルのクエリ要求用にもブロックを必要とします。ただし、複数のクエリで同じテーブルを使用している場合は、1 ブロックの割り当てで済みます。

Qcache_lowmem_prunes システム変数の情報は、クエリのキャッシュ サイズを調節するときに役立ちます。この変数は、新しいクエリのキャッシュを入れるために取り除かれたクエリの数をカウントしています。クエリ キャッシュでは、古い順番にクエリをキャッシュから削除 (LRU) します。サイズの調節方法については、項4.13.3. 「クエリ キャッシュの設定」 を参照してください。

アダルトレンタルサーバー