MySQL®レプリケーションを使用すると、1つのデータベースサーバー（この記事ではソースサーバーと呼びます）を1つ以上のデータベースサーバー（この記事ではレプリカサーバーと呼びます）にレプリケートできます。 MySQLでは、レプリケーションは非同期です。これは、ソースサーバーから更新を受信するためにレプリカサーバーを永続的に接続する必要がないことを意味します。たとえば、レプリカサーバーでレプリカスレッドを停止して後で再起動すると、ソースと自動的に同期されます。
このチュートリアルでは、すべてのデータベースをソースからレプリカに複製する簡単なセットアップ（単一のソースサーバーを単一のレプリカサーバーに複製する）を提供します。
このチュートリアルを開始する前に、次の手順を実行してください。
- オペレーティングシステムをインストールします。 （この記事の手順は、CentOS®オペレーティングシステムを使用して完了します）
- mysqlをインストールする
- mysql-develをインストールします
- mysql-serverをインストールします
注： この記事の手順では、データやデータベースのない新しいサーバーセットでのレプリケーション構成について説明します。サーバー上の既存のデータがレプリケーションをスローするため、これは重要です。この手順は、Linux®の他のフレーバーにも使用できます
この記事のMySQL構成は、クラウドサーバーのプライベートIPを介して複製されます。各サーバーのプライベートIPをメモします。
出典：
[user@mysql-source ~]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 40:40:51:B7:A4:2E
inet addr:67.23.9.185 Bcast:67.23.9.255 Mask:255.255.255.0
inet6 addr: fe80::4240:51ff:feb7:a42e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28878 errors:0 dropped:0 overruns:0 frame:0
TX packets:15147 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:37708534 (35.9 MiB) TX bytes:1129533 (1.0 MiB)
eth1 Link encap:Ethernet HWaddr 40:40:1A:AF:35:F2
inet addr:10.176.41.72 Bcast:10.176.63.255 Mask:255.255.224.0
inet6 addr: fe80::4240:1aff:feaf:35f2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:230 (230.0 b) TX bytes:762 (762.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1に表示されるIPをメモします 。 IPアドレスはinet addr:の直後に表示されます 。この例では、ソースサーバーのプライベートIPは10.176.41.72です。レプリカサーバーでこれを繰り返し、プライベートIPをメモします。
レプリカ：
[user@mysql-replica ~]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 40:40:BE:90:EB:1E
inet addr:67.23.10.69 Bcast:67.23.10.255 Mask:255.255.255.0
inet6 addr: fe80::4240:beff:fe90:eb1e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:29047 errors:0 dropped:0 overruns:0 frame:0
TX packets:13527 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:37743828 (35.9 MiB) TX bytes:1473375 (1.4 MiB)
eth1 Link encap:Ethernet HWaddr 40:40:AE:5B:35:3A
inet addr:10.176.41.207 Bcast:10.176.63.255 Mask:255.255.224.0
inet6 addr: fe80::4240:aeff:fe5b:353a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:230 (230.0 b) TX bytes:762 (762.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
この例のレプリカサーバーのIPアドレスは10.176.41.207です。両方のプライベートIPをどこかに記載したら、構成を開始できます。
-
/etc/my.cnfを編集します ソースサーバー上のファイルを使用して、バイナリロギングを有効にし、サーバーの名前を設定します。
[user@mysql-source ~]$ sudo vi /etc/my.cnf -
これらの行を
mysqldの下に追加します セクション。log-bin=/var/lib/mysqllogs/RackspaceServerID-theServerShortName-binary-log expire_logs_days=7 server-name=<server_number> -
レプリケーションユーザーを設定します。
mysql> GRANT REPLICATION SLAVE ON *.* to 'replicant'@'slaveIP' IDENTIFIED BY 'somepassword';
ソースmy.cnf 構成が完了しました。
-
タイムゾーンがソースとレプリカの間で一致していることを確認します。
-
次の項目を設定します：
relay-log=/var/lib/mysqllogs/RackspaceServerID-theServerShortName-relay-log relay-log-space-limit = 16G read-only=1 server-name=<server_number>
次のいずれかのオプションを選択して、データをレプリカにコピーします。
- mysqldump
- フラットファイルをコピーする
mysqldump
データディレクトリが適切なサイズであり、手順の期間中テーブルをロックできる場合は、このオプションを検討してください。
mysqldump -A --flush-privileges --master-data=1 | gzip -1 > ~rack/master.sql.gz
ダンプファイルをレプリカに転送してインポートします。
この方法では、両方のサーバーでMySQLを停止し、レプリカの邪魔にならない場所にデータディレクトリを移動します。 MySQLが両方のサーバーで停止していない場合は、バックアップを作成する必要があります。
# mv /var/lib/mysql{,.prereplication}
上記の方法のいずれかを使用して、レプリカ上のデータディレクトリをソースからのコピーに作成します。例：
# rsync -azv --progress --delete /var/lib/mysql/ slave:/var/lib/mysql/
データのコピーが完了したら、両方のサーバーでMySQLを再起動します。 innodb-log-file-sizeを確認します /etc/my.cnfにあります レプリカとソースで同じに設定されているか、MySQLがレプリカで起動しません。
レプリカがMySQLの新しいバージョンである場合は、mysql_upgradeを実行します。 start slaveを発行する前のレプリカ コマンド。
バックアップに対応するソースからのバイナリログのファイル名と位置が必要です。 mysqldumpを使用している場合 、これは master.sql.gzに含まれます ファイル自体。
# zgrep -m 1 -P 'CHANGE MASTER' master.sql.gz
CHANGE MASTER TO MASTER_LOG_FILE = '<binary log filename>', MASTER_LOG_POS = <binary log position>;
MySQLをシャットダウンしてrsyncを使用して取得したコールドコピーなどのファイルレベルのコピーの場合 、バイナリログのファイル名と位置は、MySQLの再起動後に作成される最初のログファイルになります。
これは、次の手順で取得できます。
# service mysqld stop
# tail -n 1 /var/lib/mysqllogs/db1-1234-bin-log.index
/var/lib/mysqllogs/db1-1234-bin-log.000001
# rsync ...
# service mysqld start
この場合、ファイル名db1-bin-log.000001 + 1 = db1-1234-bin-log.000002から開始します。 このファイルの先頭にあります。この結果が得られます：
MASTER_LOG_FILE = 'db1-1234-bin-log.000002', MASTER_LOG_POS = 4
次に、CHANGE MASTERを実行します レプリカで、ソースに接続するためのクレデンシャル、およびバイナリログファイルとレプリケーションを開始する位置を設定します。
mysql> change master to master_host='master-ip',master_user='userSetAbove', master_password='passwordSetAbove',master_log_file='logfile-from-above-command', master_log_pos=4;
mysql> start slave;
MySQLルートクレデンシャル
新しいレプリカが/root/.my.cnfで同じクレデンシャルを持っていることを確認してください ソースサーバーとしてのファイル。 MySQLデータベースとユーザー許可テーブルもレプリカに同期します。
MySQLデータベースをソースからインポートしたため、すべてのパスワードが同じになりました。 /root/.my.cnfを更新したのと同じように dbSourceと一致するようにdbReplicaで、 /etc/holland/backupsets/default.confを更新する必要がある場合があります rackspace_backupのソースと同じクレデンシャルを使用するファイル 。
ソース上にダミーデータベースを作成し、それがレプリカに表示されることを確認して、設定をテストします。確認したら、ダミーデータベースを削除し、レプリカが自動的に削除することを確認できます。
Last_IO_Error: error connecting to masterのようなエラーが表示された場合 、レプリケーションユーザーを手動でテストします。レプリカから、次の2つのことを試してください。
nc masterIP 3306
ここでエラーが表示された場合は、許可が間違っています。おそらく、思ったのとは異なるネットワークセグメントにいるためです。エラーは次のようになりますHost dbSlave is not allowed to connect to this MySQL server 。
mysql -ureplicant -hmasterDb -p
エラーが発生した場合、付与は間違っています。
これらのいずれかが接続に失敗した場合は、ファイアウォールを調整するか、この顧客向けにネットワークがどのように構成されているかについて正しい仮定をしていることを確認する必要があります。
レプリケーションフィルタリングを使用しないことをお勧めします。一部のテーブルをレプリカから除外する場合、推奨される唯一の方法は、次の my.cnfのいずれかを使用することです。 レプリカで構成されたオプション：
replicate-wild-do-table=dbase1.%
replicate-wild-do-table=dbase3.%
replicate-wild-ignore-table=dbase2.%
replicate-wild-ignore-table=dbase4.someTable
パターンにはワイルドカード文字%を含めることができます および\_ 、LIKEと同じ意味です パターンマッチング演算子。 literal_文字を使用する必要がある場合は、次のようにエスケープします。
replicate-wild-ignore-table=%.%\_tmp
MySQL 5.5では、データベースレベルのフィルタリングオプションは、ファイル名で大文字と小文字を区別することをサポートするプラットフォームで大文字と小文字を区別します。 lower_case_table_namesの値に関係なく、テーブルレベルのフィルタリングオプションはどのプラットフォームでも大文字と小文字を区別しません システム変数。
my.cnfの場合 ソースで有効になっている場合は、レプリカで無効にできます。レプリカでイベントスケジューラを有効にする必要がある場合は、既存のイベントがCREATE EVENT ... DISABLE ON SLAVEで作成されていることを確認してください。 次のようなものを使用します：select db, name from mysql.event where status not in
(‘disabled’,‘slavename_disabled’);
常にレプリケーションを監視します。 Emergingでは、通常、 SiteScope Content Match with check_replication.phpを使用します。 、これは通常、レプリカで実行されているsnameehttpdに存在します。
ソースでこれに対するGRANTを発行する必要があります。これは、レプリカに複製されます。
GRANT REPLICATION CLIENT ON *.* TO 'rep_monitor'@'slavePrimaryIP' IDENTIFIED BY 'somePassword';
ファイアウォールの背後にいると仮定すると、「slavePrimaryIP」はレプリカサーバー[192.168.100.x]のinternalIPアドレスである必要があります。 check_replication.php内 スクリプト、host=‘192.168.100.xを設定します 、スクリプトが実行されているサーバーの内部IP。これは通常、slavePrimaryIPと同じです。 。
アカウントマネージャーに連絡して、SiteScopeモニターのセットアップを要求してください。 URLは、監視サーバーのパブリックIPである必要があります（例：https://68.23.45.32/check_replication.php）。
注： スクリプトには、dsn listに追加の要素を含めることができます 単一のSiteScopeプローブを使用して、複数のレプリカを配列およびチェックします。 PHPのドキュメントには、最後の配列要素の後のコンマはオプションであり、省略できると記載されています。ただし、SiteScopeプローブが複数のレプリカをチェックしている場合、アラートがすぐにクリアされたときに問題が発生したレプリカが明確でない場合があります。この点で、 check_replication.phpを使用することは理にかなっています。 および対応するSiteScopeプローブが各レプリカで実行されています。
ここで、座って、レプリカサーバーをソースから複製します。レプリケーションが中断されるため、レプリカサーバーへの書き込みは絶対に行わないでください。ソースで実行されたすべての書き込みは、バイナリログとレプリケーションを介してレプリカに自動的に送信されます。 MySQLレプリケーションの詳細については、https：//dev.mysql.com/doc/refman/5.0/en/replication.htmlを参照してください。