この記事では、MySQL のマスター/スレーブ遅延処理スキームに関する関連知識を提供します。MySQL のマスター/スレーブ レプリケーションと読み書き分離は、インターネット上で一般的なデータベース アーキテクチャです。このアーキテクチャで最も批判されている部分は、シナリオ内での部分です。データの量が多く、同時実行の量が多い場合、マスターとスレーブの遅延は深刻になります。みんなが助けてくれることを願っています。
マスターとスレーブ間の遅延がこれほど大きいのはなぜですか?
# 回答: MySQL は単一のスレッドを使用して RelayLog を再生します。
再生時間を最適化して短縮するにはどうすればよいでしょうか?
回答: マルチスレッドで RelayLog を並列再生すると、時間を短縮できます。
RelayLog のマルチスレッド並列再生にはどのような問題がありますか?
回答: 複数のデータベース インスタンスと複数のスレッドが矛盾なく RelayLog を並行して再生できるように、RelayLog を分割する方法を検討する必要があります。
なぜ矛盾が生じるのでしょうか?
回答: RelayLog が異なるリプレイ スレッドにランダムに割り当てられている場合は、RelayLog に 3 つのシリアル変更レコードがあると想定します。
update account setmoney=100 ここで、 uid=58;
update account setmoney=150 where uid=58;
update account setmoney=200 where uid=58;
シングルスレッドシリアルリプレイの場合:すべてのスレーブ ライブラリとマスター ライブラリの実行シーケンスの一貫性を確保できます。
ナレーション: 最終的に、お金は 200 になります。
複数のスレッドが再生にランダムに割り当てられている場合: 複数の再生スレッドがこれら 3 つのステートメントを同時に実行します。誰が最後に実行するかは不明で、最終的なスレーブ データベースのデータはメイン データベースと異なる可能性があります。
ナレーション: 複数のスレーブ図書館には 100、150、200 の資金がある可能性がありますが、わかりません。
複数のスレーブとスレッドを割り当て、再生し、一貫したデータを取得するにはどうすればよいですか?
回答: 同じライブラリに対する書き込み操作の場合は、同じスレッドを使用して RelayLog を再生します。異なるライブラリに対する書き込み操作の場合は、複数のスレッドを使用して RelayLog を同時に再生できます。 #####################どうやってするの?
回答: ハッシュ アルゴリズム、hash(db-name) % thread-num を設計し、ライブラリ名をハッシュしてからスレッド数を調整します。これは簡単に実行できます。同じです。ライブラリに対する書き込み操作は、同じ再生スレッドによって連続して実行されます。ボイスオーバー: 異なるライブラリでの再生が並行して行われるため、再生が高速化されます。
この計画の欠点は何ですか? 回答: 多くの企業では MySQL に「複数のテーブルを持つ単一データベース」を使用していますが、この場合、データベースは依然として 1 つしかなく、RelayLog の再生速度を向上させることはできません。啓発: 「単一データベースと複数のテーブル」の DB アーキテクチャ モデルを、「複数のデータベースと複数のテーブル」の DB アーキテクチャ モデルにアップグレードします。 ナレーション: 大量のデータと大規模な同時実行を伴うインターネット ビジネス シナリオでは、「マルチデータベース」モデルには次のような他の多くの利点もあります。
(1) 非常に便利なインスタンスの拡張: DBA は非常に 異なるライブラリを異なるインスタンスに拡張するのは簡単です; (2) ビジネスに応じたライブラリの分離: ビジネスの分離、ビジネスの分離、結合と相互影響の軽減; (3) ) マイクロサービスを分割すると非常に便利です。各サービスが独自のインスタンスを持つと便利です。 #「単一データベースと複数のテーブル」シナリオでは、どのようにマルチスレッド化できるかRelayLog の並列再生は最適化されますか? 回答: データベースが 1 つしかない場合でも、トランザクションはメイン データベースで並行して実行されます。スレーブデータベース上で並行して実行されますか?新しいアイデア: メインデータベースで並列実行されるトランザクションをグループに分けて番号を付けることで、スレーブデータベースでのトランザクションの再生を並行して実行できます(メインデータベースでのトランザクションの実行)データベースはすべて準備フェーズに入り、トランザクション間に競合がないことを示します。そうでない場合は送信できません)、はい、MySQL はまさにこれを行います。 解決策: GTID ベースの並列レプリケーション。
MySQL5.7 以降、グループによって送信された情報は GTID に保存されます。mysqlbinlog ツールを使用すると、グループによって送信された内部情報を確認できます:20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=1 20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=2 20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=3 20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=4
元のログと比較すると、last_committed と sequence_number が増えています。
last_committed とは何ですか?
回答: トランザクションが送信されたときに最後に送信されたトランザクションの番号です。同じ last_committed を持つ場合、それらはグループ内にあり、再実行および実行できることを意味します。同時に。概要マスターとスレーブの同期遅延を短縮する方法である MySQL 並列レプリケーションには、次のアーキテクチャ上のアイデアのいくつかが具体化されています。
マルチスレッドは、実行時間を短縮する方法;ナレーション: たとえば、多くの crontab はマルチスレッドを使用してデータを分割し、並列実行できます。
マルチスレッドがタスクを同時にディスパッチする場合、冪等性を確保する必要があります: MySQL には、「ライブラリによる冪等性」と「commit_id による冪等性」という 2 つのメソッドが用意されており、学習する価値があります。 Voiceover : たとえば、グループ メッセージは group_id に従って冪等にすることができ、ユーザー メッセージは user_id に従って冪等にすることができます。
MySQL マスター/スレーブ同期遅延に特有:
mysql5.5: 並列レプリケーションはサポートされていないため、全員が MySQL バージョンをアップグレードする必要があります;
mysql5.6: 並列ライブラリによるレプリケーション、「マルチデータベース」アーキテクチャを使用することをお勧めします;
mysql5.7: GTID に基づく並列レプリケーション;
推奨される学習:
mysql ビデオ チュートリアル以上がMySQL のマスター/スレーブ遅延の解決策について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。