1.MySQLレプリケーションの実装

1.MySQLレプリケーションの実装

MySQLレプリケーションはかなり柔軟でシンプルな構造です.また,構築レプリケーション自体も複雑ではない.まず、コピーするMySQLサーバを構築する準備が必要です.ここでは、ホストMySQLのホスト名を「ホストマスター」、スレーブMySQLのホスト名を「ホストslave」と仮定し、両方ともデフォルトポート3306を使用する.

1.設定の準備

MySQLレプリケーションを構築するには、レプリケーショングループ内の各MySQLサーバに重複しないserver-id値が必要です.また、プライマリMySQLサーバはバイナリログを有効にする必要があります.この2つの事項がMySQLサーバのプロファイルに優先的に適用される場合、MySQLサーバは起動する必要があります.また、他のバイナリ・ログの同期方法を指定するにはsync binlog設定を使用します.バイナリ・ログ・ファイルのサイズと、バイナリ・ログをキャッシュする追加のメモリ・サイズを指定することもできます.「log-bin-trust-function-creators」設定値は、プライマリMySQLでストレージ関数またはトリガを作成したときに発生した警告メッセージを削除するために使用されます.

[mysqld]
server-id = 101
lob-bin				= binary_log
sync_binlog			= 1
binlog_cache_size		= 5M
max_binlog_size			= 512M
expire_logs_days		= 14
log-bin-trust-function-creators	= 1

依存MySQLサーバにも重複しないサーバ-idが必要です.MySQLから中継ログが生成されます.中継ログを格納するディレクトリまたは不要な中継ログを自動的に削除する場合は、「中継ログ」および「中継ログ消去」オプションを追加する必要があります.また、Slave MySQLサーバは通常読み取り専用なので、read only設定も併用したほうがいいです.

[mysqld]
server-id		= 102
relay-log		= relay_log
relay_log_purge		= TRUE
read_only

上記のすべての例の設定をプライマリサーバとセカンダリサーバのプロファイルに適用することを推奨しますが、server-idとプライマリMySQLのlog-bin設定値を適用する必要があります.
プライマリ・バイナリ・ログとサーバからの中継ログを個別のディレクトリに設定するには、log-bin設定と中継-log値を絶対パスに設定します.次の例に示します.

log-bin			= /var/mysql/binary_log

プライマリMySQLにバイナリログを正常に記録するかどうかは、プライマリMySQLサーバにログインして「Show Master STATUS」コマンドを発行するだけです.

root@localhost:(none) 22:49:40>SHOW MASTER STATUS;

この結果は、現在使用されている(レコード)バイナリ・ログ・ファイルの名前と、そのファイルに記録されているバイナリ・ログの場所を示します.ここで、バイナリ・ログ内の位置(Position)は、実際のファイル内のバイト数を表しますが、あまり気にしないで、位置値として扱うだけです.MySQLサーバがトランザクション・クエリーの処理を続行すると、この値は増加し続けます.

2.勘定科目のコピーの準備

Slave MySQLは、Masterからバイナリ・ログを取得するには、Master MySQLサーバにログインする必要があります.この場合、Slaveは使用するアカウントをレプリケーション・アカウントと呼びます.レプリケーション勘定科目は、メインMySQLで事前に準備されている必要があり、その勘定科目にはREPLICATIONSLAVE権限が必要です.したがって、以下に示すように、プライマリMySQLサーバに「repl user」というレプリケーションアカウントを作成します.

mysql > CREATE USER 'repl_user'@%' IDENTIFIED BY 'slavepass';
mysql > GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';

3.データのコピー

プライマリMySQLのデータをセカンダリMySQLサーバにインポートしてマウントする必要があります.MySQL Enterprise Backupまたはmysqldumpを使用してセカンダリMySQLにデータをコピーできます.通常、データが大きくない場合はmysqldumpが使用されますので、mysqldumpにコピーする例を見てみましょう.次のコマンドを1行として入力し、「--single-transaction」および「--master-data=2」オプションを追加する必要があります.
--single-transactionオプションを使用すると、テーブルまたはレコードをロックせずにInnoDBテーブルをバックアップできます.ここで重要なのは、バックアップ開始時のバイナリ・ログ情報(バイナリ・ログ・ファイル名と場所)を知る必要があります.また、master-data=2オプションには、バイナリ・ログの情報が一緒にバックアップ・ファイルに書き込まれるため、バイナリ・ログの情報が含まれている必要があります.master-dataオプションはバイナリ・ログの場所を決定するために必要ですが、mysqldumpプログラムは「FLUSH TABLES WITH READ LOCK」コマンドを使用してMySQLサーバのグローバル・ブート・ロックをロックできます(すべてのテーブルが読み込みロックされています).グローバル・ログインは、バイナリ・ログの場所を瞬時にロックするためにのみ使用されます.長いクエリがある場合、「FLUSH TABLES WITH READ LOCK」コマンドは、すべてのテーブルをロックするのに時間がかかる場合があります.

shell > mysqldump -uroot -p --opt --single-transaction --hex-blob --master-data=2 --routines --triggers --all-databases > mysql_data.sql

ダンプ完了後、master data.sqlファイルをSlave MySQLサーバに移動し、マウントを開始します.次の例はmaster dataです.これは、sqlファイルが/tmpディレクトリに準備されていると仮定したロードコマンドです.

mysql > SOURCE /tmp/master_data.sql

4.コピーの開始

レプリケーションを開始するだけで、すべての準備が整いました.その前に、プライマリ・サーバとセカンダリ・サーバのデータ・ステータス、およびレプリケーションの開始時にどのように同期するかを簡単に見てみましょう.

上図では、プライマリ・サーバとセカンダリ・サーバのデータ・ステータス、およびプライマリ・サーバとセカンダリ・サーバのデータを同期する方法について説明します.まず、MySQL Master 12:30からMySqldumpを使用してMasterのデータをバックアップし、13:20頃にSlaveにマウントします.では、サーバのデータマウントが完了した13時20分から、サーバのデータがメインサーバのデータより50分遅れていることがわかります.
次に、MasterとSlaveのクローンを始めましょう.コピーを開始するコマンドはCHANGE Masterコマンドで、mysqldumpでバックアップしたファイルのタイトル部分でこのコマンドを参照できます.バックアップのファイルサイズが大きいため、viなどのテキストエディタよりもlessなどのページビューアを使用してファイルを開くほうがいいです.最初のページを参照するにはlessコマンドを使用するだけなので、「q」キーを押してlessコマンドを終了し、上から22行目の「CHANGE MASTER」の先頭の行をテキストエディタにコピーします.

shell > less /tmp/mysql_data.sql

...
--
--Position to start replication or point-in-time recovery from
--

--CHANGE MASTER TO MASTER_LOG_FILE='binary_log.000007', MASTER_LOG_POS=2741;

メインMySQLサーバーのホスト名、ポート、レプリケーションユーザーアカウント、パスワードをエディタに追加し、レプリケーションコマンドを開始する準備をします.

CHANGE MATER TO MASTER_LOG_FILE='binary_log.000007',
	MASTER_LOG_POS=2741, master_host='host_master', master_port=3306,
    master_user='repl_user', master_password='slavepass'

Slave MySQLサーバーにログインしてこのコマンドを実行し、「Show SLAVE STATUS」コマンドを実行すると、コピーに関する情報がSlave MySQLに登録されていることがわかります.しかし、slave IO Runningとslave Runningはいずれも「No」であり、レプリケーション情報は登録されているだけで、同期が開始されていないことを示している.この状態で、「STARTSLAVE」コマンド(上図のようにSTARTSLAVE)を1回実行すると、上記の2つのスレッドの値がYesに変更され、サーバからプライマリサーバから12:30から13:45までのデータの差ができるだけ早く取得され、適用されます.

mysql > SHOW SLAVE STATUS\G
**************************** 1. row ******************************
		Slave_IO_State: ...
           Master_host: host_master
           Master_User: repl_user
           Master_Port: 3306
         Connect_Retry: 60
       Master_Log_File: binary_log.000007
  Read_Master_Log_Post: 2741
'''
	  Slave_IO_Running: No
     Slave_SQL_Running: No
'''

プライマリMySQLサーバのデータが12:30から13:45に変更された場合、同期は数分以内に完了しますが、データが多すぎると、より長い時間がかかる場合があります.「Show SLAVE STATUS」コマンド結果値に表示される「Seconds Behind Master」ステータス値が0の場合は、プライマリ・サーバとスレーブ・サーバのデータが完全に同期していることを示します.
「STARTSLAVE」コマンドが実行されているが、Slave IO RunningとSlave SQL Runningの状態がYesに変更されていない場合、プライマリMySQLサーバのホスト名、ポート、またはSlaveの接続アカウントとパスワードが間違って入力される可能性が高いため、入力された情報が正しいかどうかを確認することが望ましい.また、プライマリMySQLとセカンダリMySQLの間にネットワークの問題があるかどうかを確認したほうがいいです.
リファレンス

Real MySQL