します。https：？//www.toutiao.com/i6717521873397088780/タイムスタンプ= 1569389190＆アプリ= news_article＆group_idの= 6717521873397088780＆REQ_ID = 2019092513263001002607901724F149F2
ディレクトリ
- 序文
- マスター・スレーブ・アーキテクチャ
- MHAアーキテクチャ
- PXCプログラム
- MHA与PXC
- 最終勧告
- 概要
序文
小規模なプロジェクト開発のパートナー、データベースを維持するには、一般的にインターネットデータベースに企業で使用扱う避けることができないのMysqlで、スタートアップ企業は、シングルモードを採用しています。
あなたがプレイすることができますこの方法では、それは確かに批判される、実際のプロジェクトに適用されます。
片手データ不安で、コンピュータディスクデータベースの場合には、それらピット、壊れています。
一方の同時実行データベースが限られている上、一般的に200〜500と同じテーマに関する同時の数は、もちろん、あなたがアップ追加して継続したいことも可能である、それは、MySQLの全体的な応答時間に影響を与えます。
今日3つの高MySQLクラスタアーキテクチャについて何かを言うために、古いケア、高い、いわゆる3は、「高可用性」、「高負荷」、「高パフォーマンス」のフレームワークプログラムです。
旧区は、ここでの説明だけで上から全体のクラスタソリューションを導入し、それはそう深くなりません。しかし、いくつかのオンライン不足していると、非常に重要なアイデアを話します。詳細は自分自身を見て、全体的なアーキテクチャを理解することが重要です。
マスター・スレーブ・アーキテクチャ
MySQLのマスタースレーブ・アーキテクチャは、最初のマップに、考えることが最も可能性が高いです。
マスタースレーブ方式は、マスターMySQLの実施形態から、同期スレーブMySQLのMySQLへのマスタからのデータは、データの同期は一方向である、多くの方法で私たちのミドルウェアを使用しています。
いくつかの同期スキーム（非同期、同期、準同期）、多くのオンライン導入がありますが、古い区を詳細に語られていません。
プログラムの主な特長：
1、データセキュリティの問題を解決
図2に示すように、ミドルウェアの数と関連して（例：mycat）またはツール（例：シャーディング-JDBC）読み取りおよび書き込みの分離; MySQLは全体の性能/負荷を改善します
注：別読み出し及び書き込み意味：更新されたデータ（すなわち、書き込み要求）、マスタのMySQLを操作次にMySQLからのデータに同期され、データの読み出し（リード要求）には、MySQLからアクセスされます。
私たちは、それは確かに受け入れられない、メインのMySQLの問題と、システム全体が要求を書き込むことができない、唯一の書き込みノード（メインのmysql）でマルチマスタのプログラムから、図から見ることができます。
MySQLの単一のマスターノード障害の問題、どのように解決するには？インターネットは、多くのプログラムがあると述べ、唯一の古い区が導入された、より成熟したプログラムのメーカーが採用しています。
MHAプログラム
MHAは、あなたがその役割をマスターノードの可用性の問題を解決することで見ることができます上記の名前から、マスター高可用性の略です。
現在、高可用性のMySQL MHAの面で、日本で開発された比較的成熟したソリューションです、それは高架の高可用性ソフトウェアからの主とMySQL高可用性環境での障害として良いスイッチです。MHAは、失敗したデータベースの操作を切り替える0-30秒以内に自動的に行うことができます。
示されるように、MHAマネージャー（管理ノード）とノードMHA（ノードデータ）：MHAは、2つの部分で構成さ：
私たちは、マスターノードが使用できない見つけた場合、あなたは主スイッチングおよび障害からの転送を開始し、管理ノードを監視する際に主要な役割を果たしています。
MHAは現在、主支持体は、少なくとも3つのノード、マスターからの二つを必要とマスターマルチスレーブ・アーキテクチャです。
MHAは、マスターノードの後にハングアップすることを、どのように切り替えているのですか？
1、マスターノードは、ノードから新しい候補マスターノードの再選挙でハングアップ、原理は最近、マスターノードとして、新たな候補ノードを更新し、最新のbinlogのです。
ログ中継ノード（中継ログ）との差から別の同期マスタノードと他の2、
図3は、アプリケーションが元のプライマリノードからバイナリログを格納します
図4は、別の昇降マスタノードが新しいマスタであります
5、新しいマスタであるノードから他のクラスタノードからの移行。
上記のプロセスのコアは、実際には、MHA内の事業の多くを行っている、核となるアイデアは、データの損失を防ぐために、可能な限りデータの一貫性を確保することです。一方でMHAはよくやったが、いくつかのシーンはまだ避けることができません。
別の問題は、特に高い並行性で、遅れた同じ瞬間マスターノードとノードからの一貫性のないデータであるれているデータがノードからマスターノードに同期していることです。
また、この点に関して、このような準同期モードと最適化、多くの中のMySQLは、5.7バージョンは、データの整合性を保証するために同期モードの後に添加するが、ノード間の遅延からより多くのデータが依然として存在します。
強力なデータの整合性を確保することができますプログラムはありますか？私たちは、その後、見下します。
PXCプログラム
PXC是percona公司的percona xtraDB cluster，简称PXC。它是基于Galera协议的高可用集群方案。可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据强一致性。
PXC架构中Mysql无主从之分，都是相同的。而且每个节点都是能够提供读和写，是不是很酷，那PXC是怎么实现各个节点数据强一致性的呢？
上面是个时序图，就是PXC执行的流程，小伙伴们是不是感觉很复杂，老顾可以教大家可以这样理解：
其实就是一句话，PXC的原理其实在提交事务时，确保所有的节点事务都要成功提交，才返回成功；如果其中有一个不成功，就回滚数据，返回不成功，
正因为这样的原理，就确保数据肯定是一致的，而且是实时一致；当然这样就导致性能有损耗。PXC另一个好处就是每个节点都可以提供读写请求，不管写在哪个节点，都能够保证数据强一致性。
MHA与PXC
1、MHA主要写入速度很快，但数据不是强一致性
2、PXC保证数据强一致性，但写入速度慢
那有没有取他们优点的方案呢？来一个终极方案。老顾告诉小伙伴们，其实很多方案不可能都是优点，没有缺点，不可能很完美，最主要的是要知道在什么场景下运用什么方案。
根据MHA 和 PXC方案的特点，我们可以结合自己的业务去决定怎么使用它们？
PXC适合存储高价值的数据，要求数据强一致性，如：账户，订单，交易等等
MHA适合存储低价值的数据，不要求强一致性，如：权限，通知，日志，商品数据，购物车等等
现实情况，很多大厂都是结合使用的，我们看看2017年天猫双11，数据库峰值4200万次/秒，支付峰值25.6万次/秒；这个支付峰值已经创造了一个世界记录（国人的骄傲）。
我们发现支付场景的峰值相对其他业务的峰值比较低，这个是因为支付场景肯定是要求数据强一致性的，只要涉及到钱，用户都会很在意。
最终推荐方案
两种方案的结合，因为PXC架构都可以写，所以在入口处放一个HAProxy作负载均衡，客户端只要访问HAProxy的地址就行了，不需要知道每个PXC节点的地址。
データベース・アクセス・ミドルウェアでは、確かにデザインはもちろん、良い点を行うには、あなたが重視設定することができ、クラスタ環境にどのようなデータを、明確にする必要があり、ビジネスパッケージを行うためにそこにあります（事業が実際に決定されるため、それは、必要ありません）
概要
インターネット上の多くの小さなパートナーは、プログラムの何テイク全世界が存在しない、プログラムが良くない何が良いプログラムを、お願いしたい、これは非現実的で、多くのプログラムの選択は、関連するビジネスシーンを組み合わせることです。
MHAとPXC多くの詳細については、旧区は、あなた自身を見ることができ、多くのオンライン紹介があり、ここで提示されていません。
うまくいけば、この記事はあなたの心を開くことができ、ありがとうございました！！！