PDF (US Ltr)
- 26.9Mb
PDF (A4)
- 26.9Mb
HTML Download (TGZ)
- 7.1Mb
HTML Download (Zip)
- 7.2Mb
[+/-]
以降のセクションでは、mysqld オプション、およびレプリケーションで使用されてバイナリログを制御するためのサーバー変数の情報について説明します。レプリケーションマスターとレプリケーションスレーブで使用されるオプションと変数のうち、バイナリロギングに関係するオプションおよび変数であるものは、別途説明します。これらのオプションと変数に関する基本情報するクイックリファレンス表のセットも含まれています。
| Property | Value |
|---|---|
| コマンド行形式 | --server-id=# |
| システム変数 | server_id |
| スコープ | グローバル |
| 動的 | はい |
| 型 | 数値 |
| Default Value | 0 |
| Minimum Value | 0 |
| Maximum Value | 4294967295 |
このオプションはマスターとスレーブのどちらのレプリケーションサーバーに共通で、レプリケーションで使用され、マスターおよびスレーブサーバーがそれら自身を一意に識別できます。詳細については、セクション17.1.4.2「レプリケーションマスターのオプションと変数」,およびセクション17.1.4.3「レプリケーションスレーブのオプションと変数」を参照してください。
マスターおよび各スレーブでは、--server-id オプションを使用して、範囲が 1 から 232 − 1 の一意レプリケーション ID を確立する必要があります。「一意」とは、各 ID が、ほかのレプリケーションマスターまたはスレーブで使用されるほかのあらゆる ID と異なっている必要があるということです。たとえば、server-id=3。
--server-id を省略すると、デフォルト ID は 0 になり、この場合、マスターはすべてのスレーブからの接続を拒否し、スレーブはマスターへの接続を拒否します。MySQL 5.6 では、サーバー ID が明示的に 0 に設定されていても、デフォルトの使用が許可されていても、サーバーは server_id システム変数を 1 に設定します。これは MySQL 5.7 で修正された既知の問題です。
詳細については、セクション17.1.1.2「レプリケーションスレーブ構成の設定」を参照してください。
MySQL 5.6 以降、サーバーはユーザーが指定する --server-id に加えて真の UUID を生成します。これは、グローバルな読み取り専用変数 server_uuid として使用できます。
| Property | Value |
|---|---|
| システム変数 | server_uuid |
| スコープ | グローバル |
| 動的 | いいえ |
| 型 | 文字列 |
起動時、MySQL サーバーは次のように自動的に UUID を取得します。
auto.cnf ファイルは、my.cnf または my.ini ファイルに使用されるものに類似した形式です。MySQL 5.6 では、auto.cnf に単一 server_uuid 設定と値を含む、単一 [auto] セクションのみがあります。ファイルの内容は次に示すものに似ています。
[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562重要
auto.cnf ファイルは自動的に生成されます。このファイルを書き込んだり修正したりしようとしないでください。
MySQL 5.6 以降では、MySQL レプリケーションを使用するときに、マスターとスレーブは互いの UUID がわかります。スレーブの UUID の値は SHOW SLAVE HOSTS の出力で確認できます。START SLAVE が実行されたあとは (前ではありません)、マスターの UUID の値はスレーブでは SHOW SLAVE STATUS の出力で確認できます。
注記
STOP SLAVE または RESET SLAVE ステートメントを発行しても、スレーブで使用されるマスターの UUID はリセットされません。
MySQL 5.6.5 以降では、サーバーの server_uuid は、そのサーバーで発生するトランザクションの GTID でも使用されます。詳細は、セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。
起動時に、スレーブ I/O スレッドは、そのマスターの UUID がそれ自身と等しい場合、--replicate-same-server-id オプションが設定されている場合を除き、エラーを生成して中断します。また次のどちらかが true の場合、スレーブ I/O スレッドは警告を生成します。
予期された
server_uuidを持つマスターが存在しない。CHANGE MASTER TOステートメントがこれまで実行されなかったのみ、マスターのserver_uuidが変化した。
注記
MySQL 5.6 で server_uuid システム変数が追加されても、このセクションですでに説明したように、MySQL レプリケーションの準備と実行の一部として MySQL サーバーごとに一意の --server-id を設定する必要があることは変わりません。
replicate-do-db=from_name
and
replicate-rewrite-db=from_name->to_name
be aware that you need to actually say
replicate-do-db=to_name
because the rewrite rule apparently happens before
the do-db rule.
thanks to Therion on opn/freenode for
troubleshooting this with me.
applies to replicate-wild-do-table.
replicate-wild-do-table = LocalTableName.%
replicate-rewrite-db = RemoteTableName ->
LocalTableName
replicate-wild-do-table=db_name.% configuration
option. In 4.0.4, this option caused updates to
any specified tables to not work for me.
I had read in the documentation that this was
needed for cross database updates, but it was
causing my same database updates to fail.
I had the following options set in my slave my.cnf:
server-id = 16
master-host = 64.xx.xx.xx
master-user = replicator
master-password = *****
replicate-wild-do-table = banner.%
replicate-do-db = banner
report-host = 64.xx.xx.xx
Also, worth mentioning is that there seems to be
some limit in the server-id's, initially i set my
server-id to 15001 and this caused replication to
fail silently to even start up. Changed it to 16,
and it works perfectly, all this despite the
alleged limit of 2^32-1.
A -> B -> A
I got in running with mysql 4.0.13-max, using MyISAM and InnoDB tables.
Here's how I do it on A:
- enable bin-log (just add log-bin in /etc/my.cnf. Restart mysqld if necessary.)
- create a replication user on A (I give it all privileges. You probably shouldn't do that).
- execute query
FLUSH TABLES WITH READ LOCK;
- do
tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir
- execute query
SHOW MASTER STATUS;
write down the result for
- modify /etc/my.cnf to include
server-id=<number-of-your-choice>
- shutdown mysqld on A (my root is password-protected, and I do it from another terminal)
mysqladmin -uroot -p shutdown
- start it back up
on B (make sure there are NO update queries on B at this point):
- make sure mysqld is dead
- copy and untar mysql-snapshot.tar created earlier
- copy my.cnf from A, put DIFFERENT number in server_id.
- start mysqld (make sure binary log is enabled)
- execute queries (this is where you put the values you got earlier from SHOW MASTER STATUS on A):
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='<A host name>',
MASTER_USER='<replication user name>',
MASTER_PASSWORD='<replication password>',
MASTER_LOG_FILE='<recorded log file name>',
MASTER_LOG_POS=<recorded log offset>;
START SLAVE;
- execute query
SHOW MASTER STATUS;
write down the values
At this point you got A->B replication
on A again:
- copy B's *.bin.* (binary logs), put it in A's data dir
- execute queries (this is where you put the values you got earlier from SHOW MASTER STATUS on B):
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='<B host name>',
MASTER_USER='<replication user name>',
MASTER_PASSWORD='<replication password>',
MASTER_LOG_FILE='<recorded log file name>',
MASTER_LOG_POS=<recorded log offset>;
START SLAVE;
And you're done! If you do what I do, you will have the same user on both A and B, and this replication setup :
A -> B -> A
You can now execute any query on any of them, and it will appear on both. You can even call it a mysql cluster.
and restart the replication properly.
With A->B replication this is easy -- either switch masters as described in the Replication FAQ, or copy the slave back to the master, reset all the logs, and start again.
With A->B->A replication I would never be certain that I had reset correctly, or even that all my last transactions before the failure were all on the same machine! So I wouldn't do it. It's a low-reliability system, which kind of defeats the purpose (for me) of replication.
slave-skip-errors is _not_ a good idea on dual-masters. If you have a dual-master setup you must ensure that writes go to one master, or that you run version 5+ and use the auto_increment offset and increment options.
If you use the slave-skip-errors option suggested by a previous commenter you will end up with hopelessly inconsistent data. With the slave-skip-errors set as suggested there will be records on one machine with the same primary key id, but different column values.
It is also difficult to ascertain the proper log positions when trying to restore a failed master when both masters are written to.
Never use both sides for writes as statements need time to get to the slave. For example:
- Sending two update on the same value makes it unpredictable which one will be the final one (you may even end up with different values on the two sides)
- Doing queries that use auto-incremented fields may give different results depending on which node you are when you just incremented the field.
- If sync breaks you loose the executed but not replicated queries on one side. If the sync breaks because of connection error between A-B but they are reachable from clients, you may en up with a completely screwed up db! (example client->frontend, replication->backend)
This setup is more a kind of HA/switchover setup than clustering...
If you want HA and clustering and use only 'basic' mysql features do:
- ABA setup in failover setup
- add VRRP'ed IP seen by slave farm as master (and same users to A and B; you may as well fire up the ABA setup for the 'mysql' db)
- separate rw and ro operations in clients, use A(B) for writes and use the slave farm for ro
- loadbalance between slaves (choose you flavour for lb)