Question

A.14.1.

レプリカは常にソースに接続する必要がありますか。

Answer 1

いいえ、その必要はありません。レプリカは、数時間または数日間停止するか切断されたままにしてから、再接続して更新に追いつけます。たとえば、リンクが散発的にのみ、短時間にわたって稼働しているダイアルアップリンクを介して、ソース/レプリカ関係を設定できます。これは、特別な対策をとらないかぎり、いつでもレプリカがソースと同期していることが保証されないことを意味します。

切断されたレプリカに対してキャッチアップが発生するようにするには、まだレプリカにレプリケートされていない情報を含むバイナリログファイルをソースから削除しないでください。非同期レプリケーションは、レプリカが最後にイベントを読み取った時点からバイナリログの読み取りを続行できる場合にのみ機能します。

Answer 2

はい、ソースおよびレプリカでネットワーキングを有効にする必要があります。ネットワーキングが有効になっていない場合、レプリカはソースに接続してバイナリログを転送できません。どちらのサーバーの構成ファイルでも、skip_networking システム変数が有効になっていないことを確認します。

Answer 3

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

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

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 が共同ソース 1 を更新し、その間にクライアント B が共同ソース 2 に伝播する前に、クライアント A の更新が共同ソース 1 とは異なる方法で動作するように共同ソース 2 を更新できます。したがって、クライアント A の更新によって共同ソース 2 が作成されると、共同ソース 2 からのすべての更新も伝播された後でも、共同ソース 1 とは異なるテーブルが生成されます。これは、どのような順序でも更新が安全に行われるという確証がある場合、またはクライアントコードで更新順序の間違いに対処できる場合を除いて、2 つのサーバーを二方向レプリケーション関係にするべきではないことを意味します。

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

Answer 6

1 つのサーバをソースとして設定し、すべての書き込みをそのサーバに指示します。次に、予算およびラックスペースがある数のレプリカを構成し、ソースとレプリカ間で読取りを分散します。レプリカは、--skip-innodb オプションを使用して開始し、low_priority_updates システム変数を有効にし、delay_key_write システム変数を ALL に設定してレプリカの端の速度を向上させることもできます。この場合、レプリカは InnoDB テーブルではなく非トランザクション MyISAM テーブルを使用して、トランザクションのオーバーヘッドをなくすことで高速になります。

Answer 7

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

Answer 8

MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどないシステムにもっとも適しています。理論上、単一ソース/複数レプリケーション設定を使用すると、ネットワーク帯域幅が不足するか、ソースが処理できない時点まで更新負荷が増大するまで、レプリカを追加することでシステムをスケーリングできます。

追加されたメリットが平準化を開始する前に使用できるレプリカの数、およびサイトのパフォーマンスを向上させるためには、クエリーパターンを把握し、典型的なソースと典型的なレプリカでの読取りおよび書込みのスループット間の関係をベンチマークして経験的に判断する必要があります。ここでは、架空のシステムのレプリケーションの構成を単純に計算した例を示します。 reads および writes は、1 秒当たりの読み取りおよび書き込みの数をそれぞれ示しています。

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

reads = 1200 - 2 * writes

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

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

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

最後の方程式は、最大可能読取り速度が 1,200/秒で、書込み当たり 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.4.8「フェイルオーバー中のソースの切替え」を参照してください。

Answer 10

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

mysql> SHOW VARIABLES LIKE 'binlog_format';

表示される値は、常に STATEMENT、ROW または MIXED のいずれかです。 MIXED モードでは、ステートメントベースのロギングがデフォルトで使用されますが、レプリケーションは安全でないステートメントなどの特定の条件下で行ベースのロギングに自動的に切り替わります。これが発生する可能性がある状況の詳細は、セクション5.4.4.3「混合形式のバイナリロギング形式」を参照してください。

Answer 11

レプリカは、使用するフォーマットを自動的に認識します。

Answer 12

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

A.14.1.	レプリカは常にソースに接続する必要がありますか。
	いいえ、その必要はありません。レプリカは、数時間または数日間停止するか切断されたままにしてから、再接続して更新に追いつけます。たとえば、リンクが散発的にのみ、短時間にわたって稼働しているダイアルアップリンクを介して、ソース/レプリカ関係を設定できます。これは、特別な対策をとらないかぎり、いつでもレプリカがソースと同期していることが保証されないことを意味します。切断されたレプリカに対してキャッチアップが発生するようにするには、まだレプリカにレプリケートされていない情報を含むバイナリログファイルをソースから削除しないでください。非同期レプリケーションは、レプリカが最後にイベントを読み取った時点からバイナリログの読み取りを続行できる場合にのみ機能します。
A.14.2.	レプリケーションを有効にするには、ソースとレプリカでネットワーキングを有効にする必要がありますか。
	はい、ソースおよびレプリカでネットワーキングを有効にする必要があります。ネットワーキングが有効になっていない場合、レプリカはソースに接続してバイナリログを転送できません。どちらのサーバーの構成ファイルでも、`skip_networking` システム変数が有効になっていないことを確認します。
A.14.3.	レプリカがソースと比較してどの程度遅れているかを知るにはどうすればよいですか。つまり、レプリカによってレプリケートされた最後のステートメントの日付を知るにはどうすればよいですか。
	`SHOW REPLICA \| SLAVE STATUS` からの出力の `Seconds_Behind_Master` カラムを確認します。セクション17.1.7.1「レプリケーションステータスの確認」を参照してください。レプリケーション SQL スレッドは、ソースから読み取られたイベントを実行すると、独自の時間をイベントタイムスタンプに変更します。 (これにより、`TIMESTAMP` が正常にレプリケートされます。) `SHOW PROCESSLIST` の出力の `Time` カラムでは、レプリケーション SQL スレッドに表示される秒数は、最後にレプリケートされたイベントのタイムスタンプとレプリカマシンのリアルタイムの間の秒数です。これを使用して、最後にレプリケートされたイベントの日付を判別できます。レプリカがソースから 1 時間切断されてから再接続すると、`SHOW PROCESSLIST` のレプリケーション SQL スレッドに 3600 などの大きな `Time` 値がすぐに表示される場合があります。これは、レプリカが 1 時間経過したステートメントを実行しているためです。セクション17.2.3「レプリケーションスレッド」を参照してください。
A.14.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.14.5.	二方向レプリケーションを設定する場合に注意する問題はありますか。
	現在、MySQL レプリケーションでは、分散 (クロスサーバー) 更新の原子性を保証するために、ソースとレプリカ間のロックプロトコルはサポートされていません。つまり、クライアント A が共同ソース 1 を更新し、その間にクライアント B が共同ソース 2 に伝播する前に、クライアント A の更新が共同ソース 1 とは異なる方法で動作するように共同ソース 2 を更新できます。したがって、クライアント A の更新によって共同ソース 2 が作成されると、共同ソース 2 からのすべての更新も伝播された後でも、共同ソース 1 とは異なるテーブルが生成されます。これは、どのような順序でも更新が安全に行われるという確証がある場合、またはクライアントコードで更新順序の間違いに対処できる場合を除いて、2 つのサーバーを二方向レプリケーション関係にするべきではないことを意味します。二方向レプリケーションでは、実際には、更新に関してパフォーマンスはそれほど向上しません。各サーバーは、単一のサーバーで更新を行うときと同量の更新を行う必要があります。唯一の違いは、別のサーバーで発生した更新があるレプリケーションスレッドでシリアライズされるため、ロックの競合が少し少なくなることです。この利点さえも、ネットワーク遅延によって相殺されてしまうことがあります。
A.14.6.	レプリケーションを使用してシステムのパフォーマンスを改善するにはどうすればよいですか。
	1 つのサーバをソースとして設定し、すべての書き込みをそのサーバに指示します。次に、予算およびラックスペースがある数のレプリカを構成し、ソースとレプリカ間で読取りを分散します。レプリカは、`--skip-innodb` オプションを使用して開始し、`low_priority_updates` システム変数を有効にし、`delay_key_write` システム変数を `ALL` に設定してレプリカの端の速度を向上させることもできます。この場合、レプリカは `InnoDB` テーブルではなく非トランザクション `MyISAM` テーブルを使用して、トランザクションのオーバーヘッドをなくすことで高速になります。
A.14.7.	パフォーマンスがより高いレプリケーションを使用するには、アプリケーションのクライアントコードを準備するときに何を行えばよいですか。
	スケールアウトソリューションとしてレプリケーションを使用するためのガイドについては、セクション17.4.5「スケールアウトのためにレプリケーションを使用する」を参照してください。
A.14.8.	MySQL レプリケーションによってシステムのパフォーマンスが向上するのは、どのような場合でどの程度向上しますか。
	MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどないシステムにもっとも適しています。理論上、単一ソース/複数レプリケーション設定を使用すると、ネットワーク帯域幅が不足するか、ソースが処理できない時点まで更新負荷が増大するまで、レプリカを追加することでシステムをスケーリングできます。追加されたメリットが平準化を開始する前に使用できるレプリカの数、およびサイトのパフォーマンスを向上させるためには、クエリーパターンを把握し、典型的なソースと典型的なレプリカでの読取りおよび書込みのスループット間の関係をベンチマークして経験的に判断する必要があります。ここでは、架空のシステムのレプリケーションの構成を単純に計算した例を示します。 `reads` および `writes` は、1 秒当たりの読み取りおよび書き込みの数をそれぞれ示しています。システムのロードは 10% の書き込みと 90% の読み取りで構成されていて、ベンチマークによって `reads` が 1200 - 2 * `writes` であることが判別されたとします。つまり、書き込みがない場合、システムは毎秒 1,200 回の読み取りを実行できます。書き込みの平均は読み取りの平均の 2 倍の時間がかかり、この関係はリニア (直線的) です。ソースと各レプリカの容量が同じで、ソースと `N` のレプリカが 1 つあるとします。次に、各サーバー (ソースまたはレプリカ) について次のことを実行します: `reads` = 1200 - 2 * `writes` `reads` = 9 * `writes` / (`N` + 1) (読取りは分割されますが、書込みはすべてのレプリカにレプリケートされます) 9 * `writes` / (`N` + 1) + 2 * `writes` = 1200 `writes` = 1200 / (2 + 9/(`N` + 1)) 最後の方程式は、最大可能読取り速度が 1,200/秒で、書込み当たり 9 読取りの比率が指定された場合の、`N` レプリカの最大書込み数を示します。この分析によって、次の結論が導かれます。 `N` = 0 (レプリケーションがないことを意味します) の場合、システムは毎秒 1200/11 = 109 回の書き込みを処理できます。 `N` = 1 の場合、毎秒最大 184 回の書き込みを実行できます。 `N` = 8 の場合、毎秒最大 400 回の書き込みを実行できます。 `N` = 17 の場合、毎秒最大 480 回の書き込みを実行できます。 `N` が無限に近づくと (予算も負の無限大になり)、毎秒 600 回の書き込みに近くなり、システムスループットは 5.5 倍になります。ただし、8 サーバーのみでも 4 倍近くに増えます。これらの計算では、無限のネットワーク帯域幅が想定され、システムで重要となる可能性のあるその他のいくつかの要因は無視されます。多くの場合、`N` レプリカを追加した場合、システムで何が起こるかを正確に予測するような計算を実行できないことがあります。ただし、次の質問に答えると、レプリケーションによってシステムのパフォーマンスが向上する可能性があるかどうかとその程度を判断するのに役立ちます: システムの読み取りと書き込みの比率はどれくらいですか。読み取りを減らした場合、単一のサーバーで書き込みのロードをどれくらい処理できますか。ネットワーク上で使用可能な帯域幅があるレプリカはいくつありますか。
A.14.9.	冗長性または高可用性を持たせるには、レプリケーションをどのように使用すればよいですか。
	冗長性の実装方法は、アプリケーションおよび状況によってまったく異なります。高可用性ソリューション (自動フェイルオーバーを使用) では、アクティブな監視と、元の MySQL サーバーからレプリカへのフェイルオーバーサポートを提供するカスタムスクリプトまたはサードパーティツールが必要です。プロセスを手動で処理するには、新しいサーバーと通信するようにアプリケーションを変更するか、MySQL サーバーの DNS を障害が発生したサーバーから新しいサーバーに調整して、障害が発生したソースから事前構成済レプリカに切り替えることができます。詳細およびソリューションの例については、セクション17.4.8「フェイルオーバー中のソースの切替え」を参照してください。
A.14.10.	レプリケーションソースサーバーがステートメントベースまたは行ベースのバイナリロギング形式を使用しているかどうかを確認するにはどうすればよいですか。
	`binlog_format` システム変数の値を確認します。 `mysql> SHOW VARIABLES LIKE 'binlog_format';` 表示される値は、常に `STATEMENT`、`ROW` または `MIXED` のいずれかです。 `MIXED` モードでは、ステートメントベースのロギングがデフォルトで使用されますが、レプリケーションは安全でないステートメントなどの特定の条件下で行ベースのロギングに自動的に切り替わります。これが発生する可能性がある状況の詳細は、セクション5.4.4.3「混合形式のバイナリロギング形式」を参照してください。
A.14.11.	行ベースのレプリケーションを使用するようレプリカに指示するにはどうすればよいですか。
	レプリカは、使用するフォーマットを自動的に認識します。
A.14.12.	`GRANT` および `REVOKE` ステートメントがレプリカマシンにレプリケートされないようにするにはどうすればよいですか。
	`--replicate-wild-ignore-table=mysql.%` オプションを指定してサーバーを起動し、`mysql` データベースのテーブルのレプリケーションが無視されるようにします。
A.14.13.	レプリケーションは混合オペレーティングシステムで機能しますか (たとえば、ソースは Linux 上で実行され、レプリカは macOS と Windows 上で実行されます)。
	はい。
A.14.14.	混在ハードウェアアーキテクチャでレプリケーションは機能しますか (たとえば、ソースは 64 ビットマシン上で実行され、レプリカは 32 ビットマシン上で実行されます)。
	はい。

A.14 MySQL 8.0 FAQ: レプリケーション