Oracle と MySQL の高可用性ソリューションの比較分析-mysql チュートリアル-php.cn

Oracle と MySQL の高可用性ソリューションについては、実はまとめておきたいと思っていたので、数回に分けて簡単にお話します。この比較を通じて、2 つのデータベースアーキテクチャの設計における詳細な違いについて基本的に理解できるようになります。オラクルには非常に成熟したソリューションがあります。 OOW の私の ppt から判断すると、MAA の計画は今年で 16 周年になります。この記事では主に Oracle と MySQL の高可用性ソリューションの比較分析を紹介しています。必要な方は参考にしてください。

MySQL のオープンソースの性質により、コミュニティではさらに多くのソリューションが導入されており、私の個人的な意見では、InnoDB Cluster が将来 MySQL の標準的な高可用性ソリューションになるでしょう。

現時点では、MGR が優れていますが、MySQL Cluster ソリューション、PXC、Galera などのソリューションもあります。個人的には、やはり MHA を好みます。

そこで、この記事では、RAC と MHA について説明します。 . 基本的な比較。

オラクルのソリューションは、アリババの急速な発展期に中核となるビジネスのニーズをサポートしました。巨大に見えるのはおそらくこのようなアーキテクチャシステムです。 RAC 内部は貴族とみなされており、高価な商用ストレージ、非常に高いネットワーク帯域幅要件、多数のフロントエンド小型コンピュータサービスと高額なライセンス料金を使用しています。非常に典型的な IOE クラシックアーキテクチャ。

リモート災害復旧を検討したい場合は、リソースの割り当てを 2 倍にし、予算を 2 倍にする必要があります。

MySQL のアーキテクチャソリューションは、通常の PC で十分ですが、ビジネス分割を行う場合、多くの大手インターネット企業の MySQL クラスターサイズはさらに大きくなります。いずれも数百、数千の規模になることも珍しくありません。サービスリソースが非常に多いため、ビジネスサービスへの持続可能なアクセスを確保することが技術的ソリューションの鍵となります。 MHA アーキテクチャに従う場合、MHA マネージャーノードは基本的にクラスター全体のステータスを担当します。これは、住民に関する大小のすべてを知っている近所委員会のおばさんのようなものです。

もちろん、上記の説明は一般的すぎるため、いくつかの詳細から始めましょう。たとえば、最初にインターネットについて話しましょう。

Oracle にはネットワークに対する非常に厳しい要件があり、通常、各サーバーには少なくとも 3 つの IP、パブリック IP、プライベート IP、VIP が必要であり、少なくとも 2 つのコンピューティングノードが必要です。

プライベート IP はノード間の相互信頼です。簡単に言えば、VIP は外部にあり、パブリック IP が配置されているネットワークのドリフト IP です。10g では、VIP は負荷に使用されます。 11g ではスキャン IP が使用され始めましたが、元の VIP はまだ保持されているため、Oracle のネットワーク構成要件は依然として非常に高いです。共有ストレージに関わらず、構築の核となるのはネットワーク構成であり、ネットワークは一般的です。

scan-IP は引き続き拡張可能で、以下の図に示すように、最大 3 つの scan-ip をサポートします

もちろん、この面でのハイライトは Oracle です。 TAF を理解する必要があります。私の著書「Oracle DBA Work Notes」では、次のように書きました。

TAF (透過的アプリケーションフェイルオーバー) は、Oracle で特に広く使用されています。 RAC のロードバランスは、10g バージョンから始まった複数の VIP アドレスのロードバランスから 11g バージョンの SCAN まで、大幅に改善されました。

フェイルオーバーの実装には、依然として特定の使用上の制限があります。たとえば、11g のデフォルトの SCAN-IP 実装には、実際にはデフォルトでフェイルオーバーオプションがありません。クエリを続行すると、セッションが切断されたため再接続する必要があるというメッセージが表示されます。クライアント TAF では、主にフェイルオーバー方法とフェイルオーバータイプに関するいくつかの簡単な内容について説明します。

(1)フェイルオーバー方式

フェイルオーバー方式の主な考え方は、フェイルオーバー時間を交換するか、それを実現するためにリソースを交換することです。

2 つのノードがあると仮定します。セッションがノード 2 に接続されているが、ノード 2 が突然ハングアップした場合、フェイルオーバー状況をより速く処理するために、フェイルオーバー方法には事前接続と基本の 2 つのタイプがあります。。

— 事前接続の方法は依然として多くのリソースを占有しますが、切り替えは比較的スムーズかつ高速になります。

- 基本この方法では、フェイルオーバーが発生すると、対応するリソースが切り替わります。プロセスに多少の遅れが生じますが、リソースの消費は比較的少なくなります。

簡単に言うと、基本的な方法は障害が発生した場合にのみ判断しますが、事前接続は実際のアプリケーションから雨の日に備えるためのものであり、基本的な方法はより汎用性が高く、デフォルトのフェイルオーバー方法でもあります。

(2)フェイルオーバータイプ

フェイルオーバータイプの実装は、より豊富で、より柔軟で、非常に強力です。このとき、制御の粒度はユーザー SQL の実行に基づいて制御できます。select と session の 2 つのタイプがあります。簡単な例で説明します。

たとえば、ノード 2 で大規模なクエリが実行されているとします。その結果、たとえば、実行中のクエリには 10,000 個のデータがありましたが、障害が発生したときに 8,000 個が見つかりました。が発生した場合、残りの 2,000 をどうするか。

最初の方法は、フェイルオーバーを完了し、残りの 2,000 レコードを返し続ける select を使用することです。これは、ユーザーには意識されません。

2 番目の方法はセッションです。つまり、直接切断して再度クエリを実行します。

10g バージョンでは、VIP 構成を使用したロードバランス + フェイルオーバーの構成は次のとおりです:

racdb=
(DESCRIPTION =
(ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.101)(PORT= 1521))
(ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.201)(PORT= 1521))
(LOAD_BALANCE = yes)
(FAILOVER = ON)
(CONNECT_DATA =
(SERVER= DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE= SELECT)
(METHOD= BASIC)
(RETRIES = 30)
(DELAY = 5))))
如果11g的SCAN-IP也想进一步扩展Failover，同样也需要设置failover_mode和对应的类型。
RACDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RACDB)
)
)

ログイン後にコピー

この観点から見ると、Oracle のソリューションは非常に洗練されています。 MySQL のソリューションを見てみましょう。

分散ソリューションにより、MySQL はスイスナイフのように見えます。ネットワークレベルの要件に関しては、1 つのマスターと 1 つのスレーブを適用する場合、MySQL には 4 つの IP (マスター、スレーブ) のみが必要であると言えます。 VIP、MHA_Manager (マネージャーノードを考慮))、1 つのマスターと 2 つのスレーブは 5 です。

現時点では、MySQL はいわゆるロードバランシングをネイティブにサポートしていません。これは、ミドルウェアプロキシの使用や、一定の粒度に達した後、フロントエンドビジネスを通じて転用できます。建築設計を通じてニーズに応えます。ロジックベースのレプリケーションは拡張が容易であるため、1 つのマスターと複数のスレーブが非常に一般的であり、遅延がゼロとは言えませんが、コストは非常に低く、ほとんどのインターネットビジネスのニーズに適応できます。

MHA 切り替えを引き起こす条件について言えば、ネットワークの観点から見ると、次の赤い点は潜在的なリスクです。障害が発生した場合、データを保護するため、または安定したパフォーマンスを確保するためです。独自のニーズに基づいてカスタマイズできます。この観点からすると、データが失われる可能性があります。それは決して、強い整合性を備えた可逆コピーではありません。

2 つのソリューション全体を見ると、RAC はストレージレベルでの共有に加えて、ネットワークレベルでのマルチキャストにより実際にノード間の通信コストが増加するため、ネットワークに対する大きな需要があります。がある場合、遅延は危険であり、スプリットブレインは恥ずかしいことになる可能性があります。 MySQL MHAのソリューションが配布されています。大容量環境をサポートするため、ノード間の通信コストは比較的低くなります。ただし、データアーキテクチャの観点から見ると、複製されたデータ分散方法であるため、ストレージは共有ストレージではありませんが、ストレージのコストは RAC よりも依然として高くなります (ストレージの価格ではなく、保存されるデータの量です)。