mysql レプリケーションがスレーブで 2 つの異なるスレッドを使用することを理解しています -
スレーブの選択クエリはどうですか? SELECT クエリはレプリケーション プロセスを妨げる可能性がありますか? または、SELECT クエリを実行する別のスレッドがありますか?
つまり、スレーブの選択クエリが遅いと、レプリケーションが master に遅れることがありますか?
要するに、クエリがレプリケーションに干渉する可能性があるのは、ここで問題になるのはスレッドではなく、適用されるロック (ACID とスレッド) です。スレーブにレプリケートされているマスターからの更新クエリは、スレーブの選択クエリによってブロックされる可能性があります。ただし、レプリケーション サブシステムは、ほとんどの場合、これらのクエリ ロックの問題に対処します。ダーティ リードを気にしない場合は、スレーブのトランザクション シリアライゼーション分離レベルを制限の少ないレベルに設定して、リスクを軽減できます。ただし、ダーティ リードが許容されることを確認してください。詳細については、次のリンクを参照してください: http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
あなたは遅れを心配していますが、それは遅れがあるレプリケーションスキーマで排除できるものではありません. ほとんどの場合、マスターとスレーブの間にはネットワークがあります。これにより、最初からラグが発生します。たとえば、レプリケートされた大規模なステートメントはネットワーク帯域幅を飽和させる可能性があり、これはクエリがレプリケーションをブロックするよりも頻繁に発生する可能性があります。レプリケーションは、今までも、そしてこれからも瞬時に行われることはありません。したがって、ラグについてのあなたのポイントは、このラグは完全に排除できるものではなく、対処しなければならないものであると答えることができます.
誤解しないでください。レプリケーションは高速ですが、決して瞬時ではありません。
心に留めておくべきもう 1 つのことは、レプリケーションが失敗する可能性があり、それについても計画する必要があるということです。それはある時点で起こり、それに備えておくことが不可欠です。したがって、基本的に、レプリケーションをどのように行ってもラグが発生し、それに対処できる必要があります。また、ある時点でのレプリケーションの失敗と、そこからの回復方法についても準備しておいてください。
レプリケーションは多くの場所で役立ちますが、適切なネットワーク インフラストラクチャ、災害復旧 (フェールオーバー) 中の対処方法、運用中の監視、オンラインに戻す方法など、さまざまなレベルでレプリケーションの準備を行う必要があります。壊れるとき。