＃＃＃導入＃＃＃
| データベースはすべてのアプリケーション システムの中核であるため、データベースの安定性、効率性、安全性を確保することは、すべての企業の日常業務の最優先事項です。データベースシステムに障害が発生し、サービスが提供できなくなると、システム全体が稼働できなくなる可能性があります。したがって、データベース アーキテクチャを成功させるには、高可用性設計も十分に考慮する必要があります。以下に、可用性の高い MySQL データベース システムを構築する方法を紹介します。
|
データベースはすべてのアプリケーション システムの中核であるため、データベースの安定性、効率性、安全性を確保することは、すべての企業の日常業務の最優先事項です。データベースシステムに障害が発生し、サービスが提供できなくなると、システム全体が稼働できなくなる可能性があります。したがって、データベース アーキテクチャを成功させるには、高可用性設計も十分に考慮する必要があります。以下に、可用性の高い MySQL データベース システムを構築する方法を紹介します。
DBA や運用保守の学生は、デバイスやサービスに単一ポイントが存在すると大きなリスクが生じることを知っておく必要があります。物理マシンがダウンしたり、サービス モジュールがクラッシュしたりすると、それが不可能になるためです。短期間で復旧する必要があるため、代替機器を見つけることはアプリケーション システム全体に影響を与えることは避けられません。したがって、単一点が存在しないことをどのように保証するかが私たちの重要な課題です。MySQL の高可用性ソリューションを使用すると、この問題をうまく解決できます。一般に、次のタイプがあります:
1. MySQL 独自のレプリケーションを使用して高可用性を実現する
MySQL に搭載されているレプリケーションは、よくマスタースレーブ レプリケーション (AB レプリケーション) と呼ばれるもので、マスター サーバーのスレーブ マシンを作成することで、マスター サーバーがダウンした場合に、スレーブ マシンに迅速に業務を切り替えることができます。アプリケーションの信頼性を確保するため。通常の使用。 AB レプリケーションを使用した高可用性ソリューションも、いくつかの異なるアーキテクチャに分かれています。
1. 従来の MASTER---SLAVE ソリューション
Ordinary MASTER---SLAVE は現在、国内外のほとんどの中小企業で最も一般的に使用されているアーキテクチャ ソリューションであり、その主な利点は、シンプルさ、少ない設備 (低コスト)、および容易なメンテナンスです。このアーキテクチャは、単一点の問題を解決し、システム パフォーマンスの問題を大幅に解決できます。 MASTER の後に 1 つ以上の SLAVE (マスター/スレーブ カスケード レプリケーション) を続けることができます。ただし、このアーキテクチャでは、MASTER がシステムのすべての書き込み要求を満たすことができる必要があります。そうでない場合は、読み取り圧力を共有するために水平分割が必要です。
図1＃＃＃
図 II
図 1 ～ 2 は、単一点の問題を解決し、読み取りと書き込みの分離を使用してパフォーマンスを向上させるプロセスを示しています。
2. DUAL MASTER とカスケード レプリケーションの組み合わせ
デュアル マスターと複数のスレーブは、上記のソリューションから派生したより合理的なソリューションです。このソリューションの利点は、2 つのメイン サーバーのいずれかに障害が発生した場合でも、アーキテクチャ全体を大幅に調整する必要がないことです。
図 3
図4
図5
このプロセスは上の図に示されています。しかし、図 5 の状況は非常に特殊です。つまり、MASTER-B がダウンした場合はどうすればよいでしょうか?最初に判断できるのは、すべての書き込みリクエストはいかなる影響も受けず、すべての読み取りリクエストには通常どおりアクセスできるが、すべてのスレーブ レプリケーションが中断され、スレーブ上のデータに遅れが生じることです。現時点で行う必要があるのは、すべてのスレーブに対して CHANGE MASTER TO 操作を実行し、代わりにマスター A からコピーすることです。すべてのスレーブ レプリケーションは元のデータ ソースより先に進むことができないため、データの破損や損失を避けるために、スレーブのリレー ログのタイムスタンプ情報とマスター A のタイムスタンプ情報を比較することで、正確なレプリケーションの開始点を見つけることができます。
2. MYSQL CLUSTER を使用して全体的な高可用性を実現する
現時点では、MYSQL CLUSTER を使用して全体的な高可用性を実現するソリューション (つまり、NDB CLUSTER) は国内企業ではあまり普及していません。 NDB CLUSTER ノードは実際にはマルチノード MySQL サーバーですが、データは含まれないため、インストールされていればどのマシンでも使用できます。クラスター内の SQL ノードがクラッシュしても、ノードには特定のデータが保存されないため、データは失われません。図 6 に示すように:
図6
3. MySQL 派生製品を通じて高可用性を実現する
高可用性を実現する現在の MySQL 派生製品の中で、最もよく知られ人気があるのは、GALERA CLUSTER と PERCONA XTRDB CLUSTER (PXC) です。現時点では、この記事では関連する内容については説明しませんが、興味のある学生は関連情報を参照して詳細を確認してください。図 7 と図 8 に示すように、これら 2 つのクラスターの実装方法は似ています。
図 7
図 8
4. さまざまな高可用性ソリューションの長所と短所の比較
さまざまな高可用性設計ソリューションについてのこれまでの紹介で、読者は、どのソリューションを使用しても、独自の利点がある一方で、多かれ少なかれ制限もあることに気づいたかもしれません。このセクションでは、選択プロセスの参考として、上記の主なオプションの長所と短所を分析します。
1、MySQL レプリケーション
利点: シンプルな展開、簡単な実装、および複雑でないメンテナンス これは、MySQL が本質的にサポートする機能です。また、アクティブ マシンとスタンバイ マシンの切り替えは簡単で、アクティブ マシンとスタンバイ マシンの切り替えは、サードパーティ ソフトウェアまたは自作のスクリプトを通じて自動的に完了します。
欠点: マスター ホストのハードウェアに障害が発生して復元できない場合、スレーブに送信されていないデータの一部が失われる可能性があります。
2. MySQL クラスター (NDB)
利点: 非常に高い可用性と非常に優れたパフォーマンス。各データには少なくとも 1 つのコピーが異なるホスト上にあり、冗長データのコピーはリアルタイムで同期されます。
欠点: メンテナンスがより複雑、製品が新しい、いくつかのバグがあり、現時点では基幹オンライン システムには適していない可能性があります。
3、GALERA クラスターおよび PERCONA XTRDB クラスター (PXC)
利点: 信頼性は非常に高いです。すべてのノードがすべてのデータを同時に読み書きできます。異なるホスト上に少なくとも 1 つのコピーがあり、冗長データのコピーはリアルタイムで同期されます。
欠点: クラスターの規模が拡大するにつれて、パフォーマンスはますます悪化します。
4. 必ず言及すべき DRBD ディスク ネットワーク ミラーリング ソリューション
アーキテクチャ的には、サードパーティ ソフトウェアを介してデータ同期プロセスを実装する点を除いて、レプリケーションに似ています。信頼性はレプリケーションよりも高くなりますが、パフォーマンスも犠牲になります。
利点: ソフトウェアは強力で、データは基礎となるブロック デバイス レベルで物理ホスト間でミラーリングされ、パフォーマンスと信頼性の要件に基づいてさまざまなレベルの同期を構成できます。 IO 操作は順序を維持するため、データの一貫性に関するデータベースの厳しい要件を満たすことができます。
欠点: 非分散ファイル システム環境では、ミラー データの同時表示をサポートできません。つまり、パフォーマンスと信頼性が互いに矛盾し、両方に厳しい要件がある環境には適用できません。メンテナンスコストは MySQL レプリケーションよりも高くなります。
一般的に使用されるさまざまなアーキテクチャの長所と短所について説明した後、残る問題は、実際の運用環境で使用する適切なアーキテクチャをどのように選択するかということです。この点に関しては誰もが独自の考えや経験を持っており、どの解決策が最適であるかは意見の問題です。日々の業務において、アーキテクチャの改善は一夜にして達成されるものではなく、継続的な進化、最適化、改善のプロセスとなります。
データベースに関して言えば、Getui はシングル ポイントからマスター/スレーブ、そしてマスター/スレーブの高可用性へのプロセスも経験しており、単一の MySQL redis から MySQL redis へ、そして最終的に現在の MySQL redis に至るまでのプロセスも経験しています。コーディスなどの進化。あらゆる進化は、実稼働環境における実際的な問題や問題点を解決することを目的としています。 MySQL だけの観点から見て、すべての問題 (ペインポイント) を解決できるアーキテクチャはなく、実際の状況に基づいて適切なアーキテクチャを選択する必要があります。 MySQL クラスターによって実装されたソリューションは非常に柔軟で変更可能であり、MySQL ワーカーにとって適切なアーキテクチャを選択することは課題でもあり、それが私たちが MySQL を研究し続ける動機でもあります。
