1.データベースクラスター
単一のデータベースサービスがアクセス要件を満たせない場合は、データベースクラスターソリューションを実行できます。クラスターは必然的に問題に直面します。つまり、異なるノード間のデータ整合性の問題に直面します。複数のデータベースノードを同時に読み書きする場合、すべてのノードデータの一貫性を保つにはどうすればよいですか？
1.1マスタースレーブアーキテクチャ
このとき、レプリケーションテクノロジーを使用する必要があります。レプリケートされたノードはマスターと呼ばれ、レプリケートされたノードはスレーブと呼ばれます。スレーブ自体は、他のノードのデータソースとしても使用できます。これは、カスケードレプリケーションと呼ばれます。
マスタースレーブレプリケーションはどのように実現されますか？updateステートメントは、一種の論理ログであるbinlogを記録します。このbinlogを使用して、スレーブサーバーはマスターサーバーのbinlogファイルを取得し、内部のSQLステートメントを解析して、スレーブサーバーで実行し、マスターデータとスレーブデータの整合性を維持します。
関係するスレッドは3つあります。
- ログダンプスレッド：マスターノードにはログダンプスレッドがあり、これはbinlogをスレーブに送信するために使用されます。
- I / Oスレッド：マスターに接続してbinlogを取得し、binlogを解析してリレーログ（リレーログ）を書き込みます。
- SQLスレッド：ライブラリのSQLスレッドは、リレーログの読み取りとデータベースへのデータの書き込みに使用されます。
1.2読み取りと書き込みの分離
マスター/スレーブレプリケーションスキームを実行した後、データをマスターノードに書き込むだけで、読み取り要求をスレーブノードと共有できます。このソリューションを読み取り/書き込み分離と呼びます。
PS：マスタースレーブレプリケーションと読み取りと書き込みの分離の関係は何ですか？mysqlのマスタースレーブレプリケーションとmysqlの読み取りと書き込みの分離は密接に関連しています。
- まず、マスタースレーブレプリケーションをデプロイする必要があります。マスタースレーブレプリケーションが完了した場合にのみ、これに基づいてデータの読み取りと書き込みを分離できます。
- 一般に、マスター/スレーブレプリケーションを介してデータを同期した後、データベースの同時負荷容量を改善するために読み取りと書き込みの分離が使用されます。
読み取り/書き込み分離とは、mysqlマスターサーバーでのみ書き込みを行い、mysqlスレーブサーバーでのみ読み取りを行うことを意味します。基本的な原則は、メインデータベースにトランザクションクエリを処理させ、スレーブデータベースに選択クエリを処理させることです。データベースレプリケーションは、クラスター内のデータベースへのトランザクションクエリによって引き起こされた変更を同期するために使用されます。
読み取りと書き込みの分離により、データベースサーバーのアクセス圧力をある程度軽減できますが、マスタースレーブデータの整合性の問題に特別な注意を払う必要があります。マスターに書き込んですぐにスレーブにクエリを実行し、現時点でスレーブのデータが同期されていない場合は、どうすればよいですか？
問題
マスタースレーブレプリケーションはどこで遅いですか？初期のMySQLでは、スレーブのSQLスレッドはシングルスレッドでした。マスターはSQLステートメントの並列実行をサポートできます。構成された接続の最大数は、SQLの同時実行の最大数です。スレーブのSQLは、シングルスレッドキューでのみ実行できます。メインライブラリに大量の同時実行がある場合、同期データは確実に遅延します。
スレーブライブラリのSQLスレッドを並行して実行できないのはなぜですか？たとえば、メインライブラリは複数のSQLステートメントを実行しました。最初にユーザーがコメントを投稿し、次にコンテンツを変更し、最後にコメントを削除しました。スレーブライブラリでのこれら3つのステートメントの実行順序を逆にしないでください。・
insert into user_comments(10000009,'nice'); update user_comments set content ='verygood' where id=10000009; delete from user_comments where id=10000009;
この問題を解決する方法、つまり、マスタースレーブレプリケーションの遅延を減らす方法は？
1.3遅延ソリューション
まず、マスタースレーブレプリケーションのプロセスで、MySQLがデフォルトで非同期にレプリケートされることを知っておく必要があります。つまり、マスターノードの場合、binlogが書き込まれ、トランザクションが終了して、クライアントに返されます。スレーブの場合、binlogを受信すると終了し、マスターはスレーブのデータが正常に書き込まれたかどうかを気にしません。
マスタースレーブレプリケーションの遅延を減らしたい場合、すべてのスレーブデータベーストランザクションが完了するのを待ってからクライアントに戻ることができますか？この方法は、完全同期レプリケーションと呼ばれます。データがスレーブライブラリに書き込まれた後、マスターライブラリはデータをクライアントに返します。この方法では、読み取る前にデータが正常に同期されていることを保証できますが、トランザクションの実行時間が長くなり、マスターノードのパフォーマンスが低下するという副作用を考慮することができます。
もっと良い方法はありますか？スレーブ書き込みの待ち時間を短縮するだけでなく、マスターがクライアントに戻る時間を大幅に増加させませんか？
1.マスター/スレーブ接続モード：準同期レプリケーション
非同期レプリケーションと完全同期レプリケーションの間には、準同期レプリケーションの別の方法があります。準同期レプリケーションはどのように見えますか？
メインライブラリは、クライアントから送信されたトランザクションを実行した直後にクライアントに戻ることはありませんが、ライブラリから受信してリレーログに書き込まれるbinlogの少なくとも1つを待ってから、クライアントに戻ります。マスターは長時間待機しませんが、クライアントに戻ると、最後のステップ（リレーログの読み取りとスレーブライブラリへの書き込み）しか残っていないため、データは正常に書き込まれます。
データベースで準同期レプリケーションを使用する場合は、Googleのエンジニアが提供するプラグインをインストールする必要があります。このプラグインは、mysqlプラグインディレクトリですでに利用可能です。
cd /usr/lib64/mysql/plugin/
メインライブラリとスレーブライブラリは異なるプラグインであり、インストール後に有効にする必要があります。
-- 主库执行
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=1;
show variables like '%semi_sync%';
-- 从库执行
INSTALL PLUGIN rpl_semi_sync_slave SONAME'semisync_slave.so';
set global rpl_semi_sync_slave_enabled=1;
show global variables like '%semi%';
準同期レプリケーションは、非同期レプリケーションと比較して、データのセキュリティを向上させます。同時に、ある程度の遅延も発生します。スレーブがリレーログを書き込むのを待つ必要があります。したがって、追加のネットワーク相互作用プロセスがあります。準同期レプリケーションこれは、低遅延ネットワークで最適に使用されます。
これは、メインライブラリとスレーブライブラリ間の接続の観点からスレーブデータの書き込みを確実にするためです。別のアイデアとして、マスタースレーブ同期の遅延を減らし、SQL実行による待機時間を短縮したい場合、実行のためにキューに入れる代わりに、スレーブデータベースで複数のSQLステートメントを並行して実行できるようにする方法はありますか？
2.マルチデータベース並列レプリケーション：非同期レプリケーションのGTIDレプリケーション
並列レプリケーションを実装する方法は？3つのステートメントが3つのデータベースで実行され、それぞれのデータベースで動作する場合、並行性の問題が発生しないことは確かだと想像してみてください。実行の順序も必要ありません。もちろんそうなので、3つのデータベースを操作している場合は、3つのデータベースのSQLスレッドを同時に実行できます。これは、MySQL5.6バージョンでサポートされているマルチデータベース並列レプリケーションです。
しかし、ほとんどの場合、複数のテーブルを持つ単一のデータベースがあります。データベースで並列レプリケーションを実現するにはどうすればよいでしょうか。つまり、データベース自体が同時に複数のトランザクションをサポートしていることがわかっています。これらのトランザクションをメインデータベースで並行して実行できるのに、問題がないのはなぜですか。
たとえば、これらのトランザクションは相互に干渉しないため、異なるテーブルで動作したり、異なる行で動作したりします。リソースの競合やデータへの干渉はありません。メインライブラリで並行して実行されるトランザクションは、スレーブライブラリでも確実に並行して実行できます。たとえば、マスターには3つのテーブルを同時に操作する3つのトランザクションがありますが、これらの3つのトランザクションをスレーブで並行して実行できますか？
したがって、メインライブラリで並行して実行されるトランザクションをグループに分割して番号を付けることができます。このグループのトランザクションは、スレーブライブラリでも並行して実行できます。この番号をGTID（GlobalTransaction Identifiers）と呼び、この種のマスタースレーブレプリケーションをGTIDベースのレプリケーションと呼びます。
GTIDレプリケーションを使用する場合は、構成パラメーターを変更して開くことができます。これはデフォルトで閉じられています。
show global variables like 'gtid_mode';
概要
マスターとスレーブ間の接続を最適化する場合でも、スレーブがSQLを並行して実行できるようにする場合でも、データベースレベルからマスタースレーブレプリケーションの遅延の問題を解決することがすべてです。
データベース自体のレベルに加えて、アプリケーションレベルでは、マスタースレーブ同期の遅延を減らすためのいくつかの方法もあります。マスタースレーブレプリケーションを実行した後、単一のマスターノードまたは単一のテーブルに格納されているデータが大きすぎる場合、たとえば、テーブルに数億のデータがある場合でも、単一のテーブルのクエリパフォーマンスは低下します。さらに、単一テーブルのデータ分類とデータベースノードの分割をさらに比較する必要があります。これがサブデータベースサブテーブルです。
2.サブデータベースとサブテーブル
垂直サブデータベースは、同時実行のプレッシャーを軽減します。テーブルを水平にして、ストレージのボトルネックを解決します。
1）垂直サブライブラリ
ビジネスに応じてデータベースを異なるデータベースに分割する
2）水平サブデータベースサブテーブル
特定のルールに従って、単一のテーブルのデータを複数のデータベースに配布します
3.高可用性を実現します
マスタースレーブまたはサブデータベースサブテーブルを介して、単一のデータベースノードのアクセスプレッシャーとストレージプレッシャーを軽減し、データベースパフォーマンスを向上させるという目的を達成できますが、マスターノードがダウンした場合はどうなりますか？したがって、高可用性は高性能の基礎でもあります。
1）マスタースレーブレプリケーション：従来のHAProxy +キープアライブスキームは、マスタースレーブレプリケーションに基づいています。
2）NDBクラスター：NDBクラスターストレージエンジンに基づくMySQLクラスター。参照リンク...
3）Galera：マルチマスター同期レプリケーションクラスターソリューション。
4）MHA / MMM：マルチマスター高可用性アーキテクチャであるMMM（MySQLのマスターマスターレプリケーションマネージャー）は日本人によって開発されました。Meituanのような企業も初期にはMMMを頻繁に使用していました。MHA（MySQLマスター高可用性）。
MMMとMHAはどちらも外部に仮想IPを提供し、マスターノードとスレーブノードを監視します。マスターノードに障害が発生した場合、スレーブノードをマスターノードに昇格させる必要があり、スレーブノードに不足しているデータはマスターよりもノードを埋める必要があります。VIPを新しいマスターノードにポイントします。参照リンク...
5）MGR：MySQLバージョン5.7.17によって起動されたInnoDBクラスター（MySQL Group Replicatioin（MGR）とも呼ばれます）。このパッケージには、mysqlシェルとmysql-routeが含まれています。参照リンク1、参照リンク2
要約すると、高可用性HAソリューションが解決する必要のある問題は、マスターノードがダウンしたときにマスターになるために最新のデータでスレーブをアップグレードする方法です。複数のマスターを同時に実行する場合は、マスター間のデータ複製とクライアントの接続ルーティングの問題を解決する必要があります。ソリューションが異なれば、実装の難しさも異なり、運用および保守管理のコストも異なります。
上記はアーキテクチャの最適化です。クラスター、サブデータベース、およびサブテーブルから始めて、高可用性の実現に注意を払うことができます。