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

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

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

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「レプリケーションスレッド」を参照してください。

次の手順を使用します。

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

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

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

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

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 レプリカを追加した場合、システムで何が起こるかを正確に予測するような計算を実行できないことがあります。 ただし、次の質問に答えると、レプリケーションによってシステムのパフォーマンスが向上する可能性があるかどうかとその程度を判断するのに役立ちます:

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

プロセスを手動で処理するには、新しいサーバーと通信するようにアプリケーションを変更するか、MySQL サーバーの DNS を障害が発生したサーバーから新しいサーバーに調整して、障害が発生したソースから事前構成済レプリカに切り替えることができます。

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

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

mysql> SHOW VARIABLES LIKE 'binlog_format';

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

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

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

はい。

はい。