次のセクションでは、MySQL レプリケーションに関するよくある質問に回答しています。
- A.13.1. スレーブはマスターに常時接続されている必要がありますか。
- A.13.2. レプリケーションを有効にするには、マスターとスレーブのネットワーク接続を有効にする必要がありますか。
- A.13.3. マスターと比較してスレーブがどれくらい遅れているかを判別するにはどのようにすればよいですか。言い換えると、スレーブによってレプリケートされた最後のステートメントの日付はどのように判別できますか。
- A.13.4. スレーブが追いつくまで、マスターで更新をブロックするにはどうすればよいですか。
- A.13.5. 二方向レプリケーションを設定する場合に注意する問題はありますか。
- A.13.6. レプリケーションを使用してシステムのパフォーマンスを改善するにはどうすればよいですか。
- A.13.7. パフォーマンスがより高いレプリケーションを使用するには、アプリケーションのクライアントコードを準備するときに何を行えばよいですか。
- A.13.8. MySQL レプリケーションによってシステムのパフォーマンスが向上するのは、どのような場合でどの程度向上しますか。
- A.13.9. 冗長性または高可用性を持たせるには、レプリケーションをどのように使用すればよいですか。
- A.13.10. マスターサーバーがステートメントベースのバイナリロギング形式または行ベースのバイナリロギング形式のどちらを使用しているかを判別するにはどうすればよいですか。
- A.13.11. 行ベースのレプリケーションを使用するようにスレーブに指示するにはどうすればよいですか。
- A.13.12. GRANT ステートメントおよび REVOKE ステートメントがスレーブマシンにレプリケートされないようにするにはどうすればよいですか。
- A.13.13. オペレーティングシステムが混在している場合、レプリケーションは動作しますか (たとえば、マスターは Linux で実行され、スレーブは OS X および Windows で実行されている場合)。
- A.13.14. ハードウェアのアーキテクチャーが混在している場合、レプリケーションは動作しますか (たとえば、マスターは 64 ビットマシンで実行され、スレーブは 32 ビットマシンで実行されている場合)。
A.13.1. |
スレーブはマスターに常時接続されている必要がありますか。 |
いいえ、その必要はありません。スレーブは、シャットダウンされるか、数時間または数日間切断されても、再接続してマスターの更新に追いつくことができます。たとえば、リンクが散発的に短時間接続されるダイヤルアップリンクを使用して、マスターとスレーブの関係を設定できます。これは、特殊な対応が行われていないかぎり、特定の時点でスレーブがマスターと同期されていることは保証されないことを意味します。 切断されているスレーブが追いつくことができるようにするには、スレーブにまだレプリケートされていない情報が含まれているマスターからのバイナリログファイルを削除しないでください。非同期レプリケーションは、スレーブが最後にイベントを読み取った位置からバイナリログを継続して読み取ることができる場合にのみ動作できます。 |
|
A.13.2. |
レプリケーションを有効にするには、マスターとスレーブのネットワーク接続を有効にする必要がありますか。 |
はい。マスターとスレーブのネットワーク接続を有効にする必要があります。ネットワーク接続を有効にしないと、スレーブはマスターに接続できず、バイナリログを転送できません。両方のサーバーの構成ファイルで
|
|
A.13.3. |
マスターと比較してスレーブがどれくらい遅れているかを判別するにはどのようにすればよいですか。言い換えると、スレーブによってレプリケートされた最後のステートメントの日付はどのように判別できますか。 |
スレーブの SQL
スレッドでマスターから読み取ったイベントを実行するときに、このスレッドは実行時の時間をイベントのタイムスタンプに変更します。(これにより、 |
|
A.13.4. |
スレーブが追いつくまで、マスターで更新をブロックするにはどうすればよいですか。 |
次の手順を使用します。
|
|
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
つのサーバーをマスターとして設定し、すべての書き込みをそれに指示します。そして、予算とラックスペースが許すかぎり多くのスレーブを構成し、マスターと複数のスレーブに読み取りを分散します。スレーブ側の速度を改善するには、 |
|
A.13.7. |
パフォーマンスがより高いレプリケーションを使用するには、アプリケーションのクライアントコードを準備するときに何を行えばよいですか。 |
スケールアウトソリューションとしてレプリケーションを使用するためのガイドについては、セクション17.3.3「スケールアウトのためにレプリケーションを使用する」を参照してください。 |
|
A.13.8. |
MySQL レプリケーションによってシステムのパフォーマンスが向上するのは、どのような場合でどの程度向上しますか。 |
MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどないシステムにもっとも適しています。理論的には、単一のマスターおよび複数のスレーブのセットアップを使用する場合、ネットワーク帯域幅がなくなるか、マスターで更新のロードを処理できないポイントに到達するまでは、スレーブを追加することによってシステムを拡張できます。
処理能力の上積みが横ばいになる前のスレーブの数、およびサイトのパフォーマンスを改善できる度合いを判別するには、クエリーパターンを知り、典型的なマスターおよび典型的なスレーブでの読み取りおよび書き込みのスループットの関係をベンチマークすることによって経験的に判別する必要があります。ここでは、架空のシステムのレプリケーションの構成を単純に計算した例を示します。
システムのロードは 10% の書き込みと 90%
の読み取りで構成されていて、ベンチマークによって
9 *
最後の等式は、実行可能な最大読み取り回数が毎秒
1200 回で、書き込み 1 回当たり 9
回の読み取りがある場合の
この分析によって、次の結論が導かれます。
これらの計算ではネットワーク帯域幅を無限と想定しており、システムにおいて重要である可能性があるさまざまなほかの要因が無視されています。多くの場合、
|
|
A.13.9. |
冗長性または高可用性を持たせるには、レプリケーションをどのように使用すればよいですか。 |
冗長性の実装方法は、アプリケーションおよび状況によってまったく異なります。高可用性ソリューション (自動フェイルオーバーを使用する) では、アクティブなモニタリング、および元の MySQL サーバーからスレーブへのフェイルオーバーのサポートを提供する、カスタムスクリプトまたはサードパーティーのツールが必要となります。 この処理を手動で行うには、新しいサーバーとやり取りするようにアプリケーションを変更するか、MySQL サーバーの DNS を障害が発生したサーバーから新しいサーバーに変更することによって、障害が発生したマスターから事前構成されているスレーブに切り替えることができる必要があります。 詳細およびソリューションの例については、セクション17.3.6「フェイルオーバー中にマスターを切り替える」を参照してください。 |
|
A.13.10. |
マスターサーバーがステートメントベースのバイナリロギング形式または行ベースのバイナリロギング形式のどちらを使用しているかを判別するにはどうすればよいですか。 |
表示される値は、 |
|
A.13.11. |
行ベースのレプリケーションを使用するようにスレーブに指示するにはどうすればよいですか。 |
スレーブは使用する形式を自動的に識別します。 |
|
A.13.12. |
|
|
|
A.13.13. |
オペレーティングシステムが混在している場合、レプリケーションは動作しますか (たとえば、マスターは Linux で実行され、スレーブは OS X および Windows で実行されている場合)。 |
はい。 |
|
A.13.14. |
ハードウェアのアーキテクチャーが混在している場合、レプリケーションは動作しますか (たとえば、マスターは 64 ビットマシンで実行され、スレーブは 32 ビットマシンで実行されている場合)。 |
はい。 |