Question

A.13.1.

スレーブはマスターに常時接続されている必要がありますか。

Answer 1

いいえ、その必要はありません。スレーブは、シャットダウンされるか、数時間または数日間切断されても、再接続してマスターの更新に追いつくことができます。たとえば、リンクが散発的に短時間接続されるダイヤルアップリンクを使用して、マスターとスレーブの関係を設定できます。これは、特殊な対応が行われていないかぎり、特定の時点でスレーブがマスターと同期されていることは保証されないことを意味します。

切断されているスレーブが追いつくことができるようにするには、スレーブにまだレプリケートされていない情報が含まれているマスターからのバイナリログファイルを削除しないでください。非同期レプリケーションは、スレーブが最後にイベントを読み取った位置からバイナリログを継続して読み取ることができる場合にのみ動作できます。

Answer 2

はい。マスターとスレーブのネットワーク接続を有効にする必要があります。ネットワーク接続を有効にしないと、スレーブはマスターに接続できず、バイナリログを転送できません。両方のサーバーの構成ファイルで skip-networking オプションが有効にされていないことを確認します。

Answer 3

SHOW SLAVE STATUS の出力の Seconds_Behind_Master カラムを確認してください。セクション17.1.5.1「レプリケーションステータスの確認」を参照してください。

スレーブの SQL スレッドでマスターから読み取ったイベントを実行するときに、このスレッドは実行時の時間をイベントのタイムスタンプに変更します。(これにより、TIMESTAMP が正常にレプリケートされます。)SHOW PROCESSLIST の出力で、スレーブの SQL スレッドの Time カラムに表示される秒数は、最後にレプリケートされたイベントのタイムスタンプとスレーブマシンの実際の時間の差異の秒数です。これを使用して、最後にレプリケートされたイベントの日付を判別できます。スレーブがマスターから切断されて 1 時間たってから再接続された直後の場合は、SHOW PROCESSLIST のスレーブ SQL スレッドに大きい Time 値 (3600 など) が表示されることがあります。これは、スレーブが 1 時間前のステートメントを実行しているためです。セクション17.2.1「レプリケーション実装の詳細」を参照してください。

Answer 4

次の手順を使用します。

マスターで次のステートメントを実行します。
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
```
SHOW ステートメントの出力から、レプリケーション座標 (現在のバイナリログファイル名および位置) を記録します。
スレーブで次のステートメントを発行します。ここで、MASTER_POS_WAIT() 関数への引数は、前のステップで取得したレプリケーション座標値です。
```
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);
```
この SELECT ステートメントは、スレーブが指定されたログファイルおよび位置に達するまで更新をブロックします。その時点で、スレーブがマスターと同期され、ステートメントが戻ります。
マスターで次のステートメントを発行して、更新処理がマスターでふたたび開始されるようにします。
```
mysql> UNLOCK TABLES;
```

Answer 5

現在、MySQL レプリケーションでは、分散 (サーバー間) 更新の原子性を保証するためのマスターおよびスレーブ間のロックプロトコルはサポートされていません。言い換えると、クライアント A が co-master 1 を更新し、それを co-master 2 に伝播する前にクライアント B が co-master 2 を更新した場合、クライアント A の更新が co-master 1 への更新と異なる更新になる可能性があります。このため、クライアント A の更新が co-master 2 に行われたときに、co-master 2 からの更新がすべて伝播されたあとでも、co-master 1 とは異なるテーブルとなります。これは、どのような順序でも更新が安全に行われるという確証がある場合、またはクライアントコードで更新順序の間違いに対処できる場合を除いて、2 つのサーバーを二方向レプリケーション関係にするべきではないことを意味します。

二方向レプリケーションでは、実際には、更新に関してパフォーマンスはそれほど向上しません。各サーバーは、単一のサーバーで更新を行うときと同量の更新を行う必要があります。唯一の違いは、別のサーバーで発生した更新が 1 つのスレーブスレッドに直列化されるため、ロック競合がやや少ないことです。この利点さえも、ネットワーク遅延によって相殺されてしまうことがあります。

Answer 6

1 つのサーバーをマスターとして設定し、すべての書き込みをそれに指示します。そして、予算とラックスペースが許すかぎり多くのスレーブを構成し、マスターと複数のスレーブに読み取りを分散します。スレーブ側の速度を改善するには、--skip-innodb、--low-priority-updates、および --delay-key-write=ALL オプションを指定してスレーブを起動することもできます。この場合、スレーブは InnoDB テーブルの代わりに非トランザクションの MyISAM テーブルを使用し、トランザクションのオーバーヘッドを排除して速度を上げます。

Answer 7

スケールアウトソリューションとしてレプリケーションを使用するためのガイドについては、セクション17.3.3「スケールアウトのためにレプリケーションを使用する」を参照してください。

Answer 8

MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどないシステムにもっとも適しています。理論的には、単一のマスターおよび複数のスレーブのセットアップを使用する場合、ネットワーク帯域幅がなくなるか、マスターで更新のロードを処理できないポイントに到達するまでは、スレーブを追加することによってシステムを拡張できます。

処理能力の上積みが横ばいになる前のスレーブの数、およびサイトのパフォーマンスを改善できる度合いを判別するには、クエリーパターンを知り、典型的なマスターおよび典型的なスレーブでの読み取りおよび書き込みのスループットの関係をベンチマークすることによって経験的に判別する必要があります。ここでは、架空のシステムのレプリケーションの構成を単純に計算した例を示します。reads および writes は、1 秒当たりの読み取りおよび書き込みの数をそれぞれ示しています。

システムのロードは 10% の書き込みと 90% の読み取りで構成されていて、ベンチマークによって reads が 1200 - 2 * writes であることが判別されたとします。つまり、書き込みがない場合、システムは毎秒 1,200 回の読み取りを実行できます。書き込みの平均は読み取りの平均の 2 倍の時間がかかり、この関係はリニア (直線的) です。マスターと各スレーブの容量は同じであり、1 つのマスターと N 個のスレーブがあるとします。この場合、各サーバー (マスターまたはスレーブ) は次のようになります。

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (読み取りは分散されますが、書き込みはすべてのスレーブにレプリケートされます)

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

最後の等式は、実行可能な最大読み取り回数が毎秒 1200 回で、書き込み 1 回当たり 9 回の読み取りがある場合の N 個のスレーブの書き込みの最大数を示しています。

この分析によって、次の結論が導かれます。

N = 0 (レプリケーションがないことを意味します) の場合、システムは毎秒 1200/11 = 109 回の書き込みを処理できます。
N = 1 の場合、毎秒最大 184 回の書き込みを実行できます。
N = 8 の場合、毎秒最大 400 回の書き込みを実行できます。
N = 17 の場合、毎秒最大 480 回の書き込みを実行できます。
N が無限に近づくと (予算も負の無限大になり)、毎秒 600 回の書き込みに近くなり、システムスループットは 5.5 倍になります。ただし、8 サーバーのみでも 4 倍近くに増えます。

これらの計算ではネットワーク帯域幅を無限と想定しており、システムにおいて重要である可能性があるさまざまなほかの要因が無視されています。多くの場合、N 個のレプリケーションスレーブを追加した場合のシステムの状態を正確に予測する前述と同様の計算を行うことはできません。ただし、次の質問に答えると、レプリケーションによってシステムのパフォーマンスが改善されるかどうか、およびどれくらい改善されるかを判別するのに役立ちます。

システムの読み取りと書き込みの比率はどれくらいですか。
読み取りを減らした場合、単一のサーバーで書き込みのロードをどれくらい処理できますか。
ネットワークで帯域幅を使用できるスレーブはいくつですか。

Answer 9

冗長性の実装方法は、アプリケーションおよび状況によってまったく異なります。高可用性ソリューション (自動フェイルオーバーを使用する) では、アクティブなモニタリング、および元の MySQL サーバーからスレーブへのフェイルオーバーのサポートを提供する、カスタムスクリプトまたはサードパーティーのツールが必要となります。

この処理を手動で行うには、新しいサーバーとやり取りするようにアプリケーションを変更するか、MySQL サーバーの DNS を障害が発生したサーバーから新しいサーバーに変更することによって、障害が発生したマスターから事前構成されているスレーブに切り替えることができる必要があります。

詳細およびソリューションの例については、セクション17.3.6「フェイルオーバー中にマスターを切り替える」を参照してください。

Answer 10

binlog_format システム変数の値を確認します。

mysql> SHOW VARIABLES LIKE 'binlog_format';

表示される値は、STATEMENT、ROW、または MIXED のいずれかです。MIXED モードの場合、行ベースのロギングが望ましいのですが、特定の状況では、レプリケーションがステートメントベースのロギングに自動的に切り替わります。これが発生する場合については、セクション5.2.4.3「混合形式のバイナリロギング形式」を参照してください。

Answer 11

スレーブは使用する形式を自動的に識別します。

Answer 12

--replicate-wild-ignore-table=mysql.% オプションを指定してサーバーを起動し、mysql データベースのテーブルのレプリケーションが無視されるようにします。

A.13.1.	スレーブはマスターに常時接続されている必要がありますか。
	いいえ、その必要はありません。スレーブは、シャットダウンされるか、数時間または数日間切断されても、再接続してマスターの更新に追いつくことができます。たとえば、リンクが散発的に短時間接続されるダイヤルアップリンクを使用して、マスターとスレーブの関係を設定できます。これは、特殊な対応が行われていないかぎり、特定の時点でスレーブがマスターと同期されていることは保証されないことを意味します。切断されているスレーブが追いつくことができるようにするには、スレーブにまだレプリケートされていない情報が含まれているマスターからのバイナリログファイルを削除しないでください。非同期レプリケーションは、スレーブが最後にイベントを読み取った位置からバイナリログを継続して読み取ることができる場合にのみ動作できます。
A.13.2.	レプリケーションを有効にするには、マスターとスレーブのネットワーク接続を有効にする必要がありますか。
	はい。マスターとスレーブのネットワーク接続を有効にする必要があります。ネットワーク接続を有効にしないと、スレーブはマスターに接続できず、バイナリログを転送できません。両方のサーバーの構成ファイルで `skip-networking` オプションが有効にされていないことを確認します。
A.13.3.	マスターと比較してスレーブがどれくらい遅れているかを判別するにはどのようにすればよいですか。言い換えると、スレーブによってレプリケートされた最後のステートメントの日付はどのように判別できますか。
	`SHOW SLAVE STATUS` の出力の `Seconds_Behind_Master` カラムを確認してください。セクション17.1.5.1「レプリケーションステータスの確認」を参照してください。スレーブの SQL スレッドでマスターから読み取ったイベントを実行するときに、このスレッドは実行時の時間をイベントのタイムスタンプに変更します。(これにより、`TIMESTAMP` が正常にレプリケートされます。)`SHOW PROCESSLIST` の出力で、スレーブの SQL スレッドの `Time` カラムに表示される秒数は、最後にレプリケートされたイベントのタイムスタンプとスレーブマシンの実際の時間の差異の秒数です。これを使用して、最後にレプリケートされたイベントの日付を判別できます。スレーブがマスターから切断されて 1 時間たってから再接続された直後の場合は、`SHOW PROCESSLIST` のスレーブ SQL スレッドに大きい `Time` 値 (3600 など) が表示されることがあります。これは、スレーブが 1 時間前のステートメントを実行しているためです。セクション17.2.1「レプリケーション実装の詳細」を参照してください。
A.13.4.	スレーブが追いつくまで、マスターで更新をブロックするにはどうすればよいですか。
	次の手順を使用します。マスターで次のステートメントを実行します。 `mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;` `SHOW` ステートメントの出力から、レプリケーション座標 (現在のバイナリログファイル名および位置) を記録します。スレーブで次のステートメントを発行します。ここで、`MASTER_POS_WAIT()` 関数への引数は、前のステップで取得したレプリケーション座標値です。 `mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);` この `SELECT` ステートメントは、スレーブが指定されたログファイルおよび位置に達するまで更新をブロックします。その時点で、スレーブがマスターと同期され、ステートメントが戻ります。マスターで次のステートメントを発行して、更新処理がマスターでふたたび開始されるようにします。 `mysql> UNLOCK TABLES;`
A.13.5.	二方向レプリケーションを設定する場合に注意する問題はありますか。
	現在、MySQL レプリケーションでは、分散 (サーバー間) 更新の原子性を保証するためのマスターおよびスレーブ間のロックプロトコルはサポートされていません。言い換えると、クライアント A が co-master 1 を更新し、それを co-master 2 に伝播する前にクライアント B が co-master 2 を更新した場合、クライアント A の更新が co-master 1 への更新と異なる更新になる可能性があります。このため、クライアント A の更新が co-master 2 に行われたときに、co-master 2 からの更新がすべて伝播されたあとでも、co-master 1 とは異なるテーブルとなります。これは、どのような順序でも更新が安全に行われるという確証がある場合、またはクライアントコードで更新順序の間違いに対処できる場合を除いて、2 つのサーバーを二方向レプリケーション関係にするべきではないことを意味します。二方向レプリケーションでは、実際には、更新に関してパフォーマンスはそれほど向上しません。各サーバーは、単一のサーバーで更新を行うときと同量の更新を行う必要があります。唯一の違いは、別のサーバーで発生した更新が 1 つのスレーブスレッドに直列化されるため、ロック競合がやや少ないことです。この利点さえも、ネットワーク遅延によって相殺されてしまうことがあります。
A.13.6.	レプリケーションを使用してシステムのパフォーマンスを改善するにはどうすればよいですか。
	1 つのサーバーをマスターとして設定し、すべての書き込みをそれに指示します。そして、予算とラックスペースが許すかぎり多くのスレーブを構成し、マスターと複数のスレーブに読み取りを分散します。スレーブ側の速度を改善するには、`--skip-innodb`、`--low-priority-updates`、および `--delay-key-write=ALL` オプションを指定してスレーブを起動することもできます。この場合、スレーブは `InnoDB` テーブルの代わりに非トランザクションの `MyISAM` テーブルを使用し、トランザクションのオーバーヘッドを排除して速度を上げます。
A.13.7.	パフォーマンスがより高いレプリケーションを使用するには、アプリケーションのクライアントコードを準備するときに何を行えばよいですか。
	スケールアウトソリューションとしてレプリケーションを使用するためのガイドについては、セクション17.3.3「スケールアウトのためにレプリケーションを使用する」を参照してください。
A.13.8.	MySQL レプリケーションによってシステムのパフォーマンスが向上するのは、どのような場合でどの程度向上しますか。
	MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどないシステムにもっとも適しています。理論的には、単一のマスターおよび複数のスレーブのセットアップを使用する場合、ネットワーク帯域幅がなくなるか、マスターで更新のロードを処理できないポイントに到達するまでは、スレーブを追加することによってシステムを拡張できます。処理能力の上積みが横ばいになる前のスレーブの数、およびサイトのパフォーマンスを改善できる度合いを判別するには、クエリーパターンを知り、典型的なマスターおよび典型的なスレーブでの読み取りおよび書き込みのスループットの関係をベンチマークすることによって経験的に判別する必要があります。ここでは、架空のシステムのレプリケーションの構成を単純に計算した例を示します。`reads` および `writes` は、1 秒当たりの読み取りおよび書き込みの数をそれぞれ示しています。システムのロードは 10% の書き込みと 90% の読み取りで構成されていて、ベンチマークによって `reads` が 1200 - 2 * `writes` であることが判別されたとします。つまり、書き込みがない場合、システムは毎秒 1,200 回の読み取りを実行できます。書き込みの平均は読み取りの平均の 2 倍の時間がかかり、この関係はリニア (直線的) です。マスターと各スレーブの容量は同じであり、1 つのマスターと `N` 個のスレーブがあるとします。この場合、各サーバー (マスターまたはスレーブ) は次のようになります。 `reads` = 1200 - 2 * `writes` `reads` = 9 * `writes` / (`N` + 1) (読み取りは分散されますが、書き込みはすべてのスレーブにレプリケートされます) 9 * `writes` / (`N` + 1) + 2 * `writes` = 1200 `writes` = 1200 / (2 + 9/(`N` + 1)) 最後の等式は、実行可能な最大読み取り回数が毎秒 1200 回で、書き込み 1 回当たり 9 回の読み取りがある場合の `N` 個のスレーブの書き込みの最大数を示しています。この分析によって、次の結論が導かれます。 `N` = 0 (レプリケーションがないことを意味します) の場合、システムは毎秒 1200/11 = 109 回の書き込みを処理できます。 `N` = 1 の場合、毎秒最大 184 回の書き込みを実行できます。 `N` = 8 の場合、毎秒最大 400 回の書き込みを実行できます。 `N` = 17 の場合、毎秒最大 480 回の書き込みを実行できます。 `N` が無限に近づくと (予算も負の無限大になり)、毎秒 600 回の書き込みに近くなり、システムスループットは 5.5 倍になります。ただし、8 サーバーのみでも 4 倍近くに増えます。これらの計算ではネットワーク帯域幅を無限と想定しており、システムにおいて重要である可能性があるさまざまなほかの要因が無視されています。多くの場合、`N` 個のレプリケーションスレーブを追加した場合のシステムの状態を正確に予測する前述と同様の計算を行うことはできません。ただし、次の質問に答えると、レプリケーションによってシステムのパフォーマンスが改善されるかどうか、およびどれくらい改善されるかを判別するのに役立ちます。システムの読み取りと書き込みの比率はどれくらいですか。読み取りを減らした場合、単一のサーバーで書き込みのロードをどれくらい処理できますか。ネットワークで帯域幅を使用できるスレーブはいくつですか。
A.13.9.	冗長性または高可用性を持たせるには、レプリケーションをどのように使用すればよいですか。
	冗長性の実装方法は、アプリケーションおよび状況によってまったく異なります。高可用性ソリューション (自動フェイルオーバーを使用する) では、アクティブなモニタリング、および元の MySQL サーバーからスレーブへのフェイルオーバーのサポートを提供する、カスタムスクリプトまたはサードパーティーのツールが必要となります。この処理を手動で行うには、新しいサーバーとやり取りするようにアプリケーションを変更するか、MySQL サーバーの DNS を障害が発生したサーバーから新しいサーバーに変更することによって、障害が発生したマスターから事前構成されているスレーブに切り替えることができる必要があります。詳細およびソリューションの例については、セクション17.3.6「フェイルオーバー中にマスターを切り替える」を参照してください。
A.13.10.	マスターサーバーがステートメントベースのバイナリロギング形式または行ベースのバイナリロギング形式のどちらを使用しているかを判別するにはどうすればよいですか。
	`binlog_format` システム変数の値を確認します。 `mysql> SHOW VARIABLES LIKE 'binlog_format';` 表示される値は、`STATEMENT`、`ROW`、または `MIXED` のいずれかです。`MIXED` モードの場合、行ベースのロギングが望ましいのですが、特定の状況では、レプリケーションがステートメントベースのロギングに自動的に切り替わります。これが発生する場合については、セクション5.2.4.3「混合形式のバイナリロギング形式」を参照してください。
A.13.11.	行ベースのレプリケーションを使用するようにスレーブに指示するにはどうすればよいですか。
	スレーブは使用する形式を自動的に識別します。
A.13.12.	`GRANT` ステートメントおよび `REVOKE` ステートメントがスレーブマシンにレプリケートされないようにするにはどうすればよいですか。
	`--replicate-wild-ignore-table=mysql.%` オプションを指定してサーバーを起動し、`mysql` データベースのテーブルのレプリケーションが無視されるようにします。
A.13.13.	オペレーティングシステムが混在している場合、レプリケーションは動作しますか (たとえば、マスターは Linux で実行され、スレーブは OS X および Windows で実行されている場合)。
	はい。
A.13.14.	ハードウェアのアーキテクチャーが混在している場合、レプリケーションは動作しますか (たとえば、マスターは 64 ビットマシンで実行され、スレーブは 32 ビットマシンで実行されている場合)。
	はい。

A.13 MySQL 5.6 FAQ: レプリケーション