OLTP アプリケーション用の MySQL アーキテクチャの選択_PHP チュートリアル

OLTP アプリケーション用の MySQL アーキテクチャの選択

コア エンタープライズ アプリケーションをエンタープライズ レベルのデータベースからオープン ソース データベース製品に移行し、共有ストレージの代わりにローカル ディスクを使用することを決意する前に。オープンソースを真に実行し、アイデアを実践する前に、次の質問に直面して答える必要があると思います。 OLTP アプリケーションを MySQL データベースに移行する前に、回答する必要があるいくつかの質問を見てみましょう:
(1) 極端な状況でスタンバイ データベース (プライマリ データベース) がサービスを引き継ぐことを許可された後、データに一時的な不整合はありますか? ) スレーブ アーキテクチャでは、メイン データベースがクラッシュした後、一部の書き込み操作がスタンバイ データベースと同期されないという問題が発生する可能性があります)。
(2) MySQL データベースに障害が発生すると、アプリケーション サービスも 3 ～ 30 秒間中断されます。このシナリオは許容されますか?
(3) データベースのスケーラビリティ、スループット容量、応答時間、ユーザー エクスペリエンスに関して高い要件がありますか?
上記の 3 つの質問に答えるだけで、次の 3 種類の OLTP タイプの MySQL アーキテクチャ設計ソリューションは、真に参考かつ実用的な意味を持つことができます。著者が現在検討している、OLTP アプリケーションに適したオープンソース ソリューションを見てみましょう。
計画 1. マルチマスター同期レプリケーション ソリューション PXC
PXC、つまり Percona Xtradb Cluster は、Galera エンジンを使用して同期データ レプリケーション、複数ノード間の読み取りと書き込みを実現し、データベース サービスの高可用性とデータの一貫性を確保します。そのアーキテクチャは次のとおりです:

1. PXC の利点
(1) 同期データレプリケーション
(2) 複数のノードで同時に読み取りと書き込みが可能ですが、事前にデータベースとテーブルに分割する必要があり、または、ライブラリ
(3) で厳密なデータの一貫性を確保できます
(4) 読み取りが多く書き込みが少ないビジネス システムに適しています
2. XA トランザクションをサポートしません。
(2) クラスターのスループット/パフォーマンスは応答に依存します 最も遅いノードであり、トランザクション効率はマスター/スレーブアーキテクチャよりも一桁以上低いです
(3) 調整が必要です
(4) InnoDB エンジンのみをサポートします
(5)すべてのテーブルには主キーが必要です
(6) 大規模なトランザクションは許可されていません
(7) LOCK TABLE などの明示的なロック操作はサポートされていません
(8) 書き込みの競合があり、多くのロックの競合とデッドロックの問題があり、ホットなアップデートの問題が解決できず、スケーラビリティが低い
(9) 同時トランザクションの量が多い場合その場合、ネットワーク遅延によるボトルネックを軽減するためにInfiniBandネットワークを使用することが公式推奨されています
(10)複数のサードパーティのプラグインを導入し、統合の複雑さが高くなります
オプション 2、マスター/スレーブ レプリケーション スキーム MHA
MHA はマスター高可用性マネージャーであり、Tools for MySQL は、高可用性を維持することを目的とした MySQL 高可用性管理ツールですMaster データベースの可用性とデータの一貫性。その最大の特徴は、複数のスレーブ間の差分ログを修復し、最終的にすべてのスレーブでデータの一貫性を保ち、スレーブ データベースを新しいマスターとして選択し、他のスレーブをそこにポイントできることです。
そのアーキテクチャは次のとおりです:

1. MHA の利点
1. 障害後のマスター フェイルオーバーとノード間のデータ同期を自動的に監視します
2. パフォーマンスの損失がなく、あらゆるストレージ エンジンに適しています
3. 自動データ補償機能を備えており、メインデータベースが異常終了した場合でもデータの整合性を最大限に確保できます
4. 同一都市内でアプリケーションレベルのアクティブ/アクティブを実現できます
2. 1. メインサーバーのハードウェアに障害が発生した場合、または ssh 経由でアクセスできない場合、フェイルオーバーを実行すると現在のデータが失われる可能性があります
2. 切り替え時間が長く、全体の切り替え時間は約 9 ～ 12 秒かかります
計画 3.マスター レプリケーション スキーム MM
MySQL を使用して、マスター/スレーブの一方向レプリケーションとマスター/マスターの双方向レプリケーションをネイティブにサポートするこのアーキテクチャは、メイン ライブラリの単一ポイントと書き込みボトルネックの問題を解決します。そのアーキテクチャは次のとおりです。参照してください:


1. MM アーキテクチャの利点 1. 高速スイッチングをサポートし、通常 3 秒以内にスタンバイ マシンに切り替わります
2. シンプルな構成管理、サードパーティのプラグインは不要です必須
2. MM アーキテクチャの欠点
1. データベース サーバーのハードウェアに障害が発生すると、現在の運用データが失われる可能性があります
上記の解決策の要約
(1) PXC アーキテクチャには多くの利点がありますが、非常に明らかな欠点もあります。その主な利点は、各ノード上のデータの一貫性を確保することです。欠点は、データの一貫性を確保するために、各ノードが事前にディスクにデータを書き込む必要があることです。それは完了しているので、効率の問題があります。つまり、各トランザクションの応答時間はクラスター全体で最も遅いノードに依存し、ネットワーク品質に対して非常に高い要件が課されます。もう 1 つの問題は、オープンソースの方向性がどこにあるのかを明確に検討する必要があるということです。問題は、ニッチなブランチ オープン ソース コミュニティである Percona に従うべきか、それとも主流の MySQL 公式オープン ソース コミュニティの発展に従うべきかということです。
(2) MHA アーキテクチャの利点は、MHA プラグインを使用してメイン ライブラリの単一点問題を解決し、引き継がれたスレーブ ライブラリとメイン ライブラリ間のデータの一貫性を確保しようとすることです。メイン ライブラリがハングアップする場合、データ同期機能はネイティブです。欠点は、マスター データベースのフェイルオーバー後にデータ損失がゼロであることを保証できないことです。実際、ここでのより正確な表現は、マスター データベース間でデータ損失が発生するべきではないということです。そしてスレーブデータベース。
MHA は、以下の状況下で、テイクオーバー後のノードとメイン データベース間のデータの一貫性を保証できます:
(1) ハードウェア障害がない場合、修復されたメイン データベースからデータを取得でき、DBA は手動でデータを埋めることができます。データベースをバックアップし、最終的にデータの一貫性を実現します。
(2) 単なるデータベース障害の場合、MHA は実装されたすべてのデータをスタンバイ データベースに自動的に同期して、データ損失をゼロにします。 -同期メカニズム、2 段階の送信によりデータの一貫性が保証されます。 (3) MM デュアルマスター アーキテクチャの長所と短所は、すべて MySQL のネイティブ データ同期を使用します。機構。違いは、MM アーキテクチャはプライマリに障害が発生した場合の切り替え時間が短いことです。欠点は、データの不整合が発生する可能性が高いことです。さらに、MM アーキテクチャでは、MHA データ補正ツールを導入してプライマリとセカンダリの切り替えによって引き起こされるデータの不整合の問題を最小限に抑えたり、MySQL の準同期メカニズムを直接使用してデータの整合性を確保したりすることもできます。

http://www.bkjia.com/PHPjc/1095031.html

www.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/1095031.html技術記事 OLTP アプリケーション用の MySQL アーキテクチャの選択 コア エンタープライズ アプリケーションをエンタープライズ レベルのデータベースからオープン ソース データベース製品に移行し、共有ストレージの代わりにローカル ディスクを使用することを決定する前に。私は...