マスタ サーバをコントロールする SQL ステートメント

1. PURGE MASTER LOGS 構文
2. RESET MASTER 構文
3. SET SQL_LOG_BIN 構文
4. SHOW BINLOG EVENTS 構文
5. SHOW BINARY LOGS 構文
6. SHOW MASTER STATUS 構文
7. SHOW SLAVE HOSTS 構文

複製は SQL インターフェースを通してコントロールできます。このセクションでは、マスタ複製サーバの管理についてのステートメントの説明をします。項 「スレーブ サーバをコントロールする SQL ステートメント」では、スレーブ サーバの管理について説明しています。

1. PURGE MASTER LOGS 構文

PURGE {MASTER | BINARY} LOGS TO 'log_name'
PURGE {MASTER | BINARY} LOGS BEFORE 'date'

ログ インデックス内で指定されたログや日付の前にリストされている全てのバイナリ ログを削除します。与えられたログが最初になるように、ログ インデックス ファイル内に記録されたリストからもログが削除されます。

例:

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';

BEFORE 異型の date 引数は 'YYYY-MM-DD hh:mm:ss' フォーマットになり得ます。MASTERBINARY は同義語です。

このステートメントは、スレーブが複製中に起動しても安全です。それらを停止させる必要はありません。現在削除しようとしているログの1つを読み込んでいる、アクティブ スレーブを持っていれば、このステートメントは何もせず、エラーで失敗します。しかし、もしスレーブが休止状態で、まだ読み込まれていないログの1つを消去してしまったら、そのスレーブはその後複製が不可能になります。

ログを安全に消去するには、次の手順に従ってください。

  1. 各スレーブ サーバ上で、どのログがそれを読み込んでいるのか確認する為に SHOW SLAVE STATUS を利用してください。

  2. SHOW BINARY LOGS を利用してマスタ サーバ上でバイナリ ログのリストを手に入れてください。

  3. 全てのスレーブの中で一番最初のログを確認してください。.これがターゲット ログです。もし全てのスレーブが最新であれば、これがリスト上の最後のログになります。

  4. 削除しようとしている全てのログのバックアップを作成してください。(このステップは任意ですが、常に推奨されている物です。)

  5. ターゲット ログを含まず、そこまでの全てのログを消去してください。

指定した日数後に(項 「システム変数」 を参照)バイナリ ログを自動的に無効にする expire_logs_days システム変数も設定できます。もし複製を利用しているなら、ご利用のスレーブがマスタよりも遅れるであろう最大日数よりも低く変数を設定しなければいけません。

2. RESET MASTER 構文

RESET MASTER

インデックス ファイル内にリストされている全てのバイナリ ログを削除し、バイナリ ログ インデックス ファイルをゼロにリセットし、新しいバイナリ ログを作成します。

3. SET SQL_LOG_BIN 構文

SET SQL_LOG_BIN = {0|1}

もしクライアントが SUPER 権限を持っていたら、現在の接続(SQL_LOG_BIN がセッション変数です)のバイナリ ログを無効、または有効にします。もしクライアントがその権限を持っていなければ、ステートメントはエラーによって拒否されます。

4. SHOW BINLOG EVENTS 構文

SHOW BINLOG EVENTS
   [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

バイナリ ログ内のイベントを表します。もし 'log_name' を指定しなければ、最初のバイナリ ログが表示されます。

LIMIT 条項は SELECT ステートメントに対するのと同じ構文を持っています。詳しくは 項 「SELECT 構文」 を参照してください。

注意:LIMIT を利用せずに SHOW BINLOG EVENTS を発行すると、サーバがクライアントに完全なバイナリ ログのコンテンツ(データを変更するサーバによって実行された全てのステートメントを含む)を返すので、時間、リソースの両方を大量に消費するプロセスを開始する事になってしまいます。SHOW BINLOG EVENTS の代替として、後ほど行う調査と分析の為のバイナリ ログをテキスト ファイルに保存する為に mysqlbinlog ユーティリティを利用してください。詳しくは 項7.10. 「mysqlbinlog — バイナリログファイルを処理するためのユーティリティ」 を参照してください。

5. SHOW BINARY LOGS 構文

SHOW BINARY LOGS
SHOW MASTER LOGS

サーバ上にバイナリ ログをリストします。このステートメントは、どのログを消去できるかを決める方法を表す 項1. 「PURGE MASTER LOGS 構文」 内で説明されている手順の一部として利用されています。

mysql> SHOW BINARY LOGS;
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000015 |    724935 |
| binlog.000016 |    733481 |
+---------------+-----------+

SHOW MASTER LOGSSHOW BINARY LOGS と同等です。

6. SHOW MASTER STATUS 構文

SHOW MASTER STATUS

マスタのバイナリ ログ ファイルについてのステータス情報を提供します。例:

mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73       | test         | manual,mysql     |
+---------------+----------+--------------+------------------+

7. SHOW SLAVE HOSTS 構文

SHOW SLAVE HOSTS

現在マスタと共に登録されている複製スレーブのリストを表示します。このリスト内では、--report-host=slave_name オプションを利用してスタートされたスレーブのみ見る事ができます。

このリストはどのサーバ上にも表示されます。(マスタサーバだけではありません。)アウトプットはこのようになります。

mysql> SHOW SLAVE HOSTS;
+------------+-----------+------+-----------+
| Server_id  | Host      | Port | Master_id |
+------------+-----------+------+-----------+
|  192168010 | iconnect2 | 3306 | 192168011 |
| 1921680101 | athena    | 3306 | 192168011 |
+------------+-----------+------+-----------+
  • Server_id:サーバのオプション ファイル内、または --server-id=value を利用したコマンド ライン上で設定された、ユニーク サーバ ID です。

  • Host:サーバのオプション ファイル内、または --report-host=value を利用したコマンド ライン上で設定された、スレーブ サーバのホスト名です。

    OS 内で設定されたマシン名とは異なる可能性があるという事に注意してください。

  • Port:スレーブ サーバが聴いているポート

  • Master_id:スレーブ サーバがそこから複製している、マスタ サーバのユニーク サーバ ID。

いくつかの MySQL バージョンは別の変数 Rpl_recovery_rank を報告します。この変数が利用された事はなく、最終的に削除されました。