Oracle と MySQL の高可用性ソリューションの比較分析

Oracle と MySQL の高可用性ソリューションについては、以前からまとめたいと思っていたので、いくつかのシリーズに分けて簡単に説明します。このような比較を通じて、2 つのデータベース アーキテクチャの設計における詳細な違いを基本的に理解できるようになります。 Oracle は非常に成熟したソリューションを提供しています。 OOW に投稿した PPT から判断すると、これは MAA プログラムであり、今年はこのプログラムの 16 周年にあたります。

MySQL はオープンソースであるため、コミュニティではさらに多くのソリューションが立ち上げられています。私の個人的な意見では、InnoDB Cluster は将来 MySQL の標準的な高可用性ソリューションになるでしょう。

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

したがって、この記事は解釈のためにいくつかの部分に分割されます。まず、RAC と MHA の基本的な比較を行います。

Oracle のソリューションは、急速な発展期における Alibaba のコアビジネス ニーズをサポートしました。これはおそらく建築システムであり、巨大に見えます。そこに含まれる RAC は、高価な商用ストレージを使用し、非常に高いネットワーク帯域幅要件を備え、フロントエンドに多数の小規模マシン ビジネスと高額なライセンス料がかかる、高貴なものであると考えられています。非常に典型的な IOE クラシック アーキテクチャです。

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

MySQLのアーキテクチャは比較的普及しており、普通のPCにインストールできますが、規模は大きくなります。業務を分割して水平分割することで、多数のノードを水平に拡張できます。多くの大手インターネット企業のMySQLクラスタの規模は数百、数千になることも珍しくありません。サービス リソースが非常に多いため、障害が発生する可能性は依然としてあります。ビジネス サービスへの継続的なアクセスを確保することが、技術的なソリューションの鍵となります。 MHA アーキテクチャによれば、MHA マネージャー ノードは基本的に、住民に関する大小さまざまなことをすべて把握している近所の委員のおばさんのように、クラスター全体のステータスを担当します。

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

Oracle では、ネットワークに対して非常に厳しい要件があります。通常、2 つの物理ネットワーク カードが必要です。各サーバーには、パブリック IP、プライベート IP、VIP を含む少なくとも 3 つの IP が必要です。共有ストレージに加えて、少なくとも 2 つのコンピューティング ノードが必要です。

プライベート IP はノード間で相互に信頼されます。パブリック IP と VIP は同じネットワーク セグメントにあります。簡単に言えば、VIP は外部であり、パブリック IP が配置されているネットワークの漂流 IP です。10g では、負荷分散は VIP を通じて行われます。11g ではスキャン IP が導入され、元の VIP が保持されているため、Oracle のネットワーク構成要件は依然として非常に高くなっています。共有ストレージはともかく、構築の核となるのはネットワーク構成であり、ネットワークが繋がっていれば繋がることになります。

スキャンIPはさらに拡張可能で、次の図に示すように最大3つのスキャンIPをサポートできます。

もちろん、ネットワーク層にはこれ以外にも多くの機能があり、Oracle はこの分野で非常に専門的です。 TAF を理解する必要があります。私の著書「Oracle DBA Work Notes」では、次のように書いています。

TAF (Transparent Application Failover) は、アプリケーションに対して透過的な Oracle のフェイルオーバー機能であり、特に RAC 環境で広く使用されています。 RAC では、バージョン 10g の複数の VIP アドレスのロード バランシングからバージョン 11g の SCAN まで、ロード バランシングが大幅に改善され、大幅に簡素化されました。

ただし、フェイルオーバーの実装には依然として一定の使用制限があります。たとえば、11g のデフォルトの SCAN-IP 実装には、デフォルトではフェイルオーバー オプションがありません。2 つのノードのうちの 1 つに障害が発生した場合、元の接続でクエリを続行すると、セッションが切断され、再接続する必要があることが示されます。クライアント TAF では、主にフェイルオーバー方法とフェイルオーバー タイプの簡単な内容について説明します。

（１）フェイルオーバー方式

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

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

— 事前接続 この事前接続方法では、依然として多くのリソースが使用されます。各ノードで追加のリソースが事前に占有されるため、切り替えがよりスムーズかつ高速になります。

— この基本的な方法では、フェイルオーバーが発生すると、対応するリソースが切り替えられます。途中で多少の遅延が発生しますが、リソースの消費は比較的少なくなります。

簡単に言えば、基本方式は障害が発生したときにのみ判断を行い、事前接続は予防措置です。実際のアプリケーションの観点からは、基本方式の方が一般的であり、デフォルトのフェイルオーバー方式です。

（２）フェイルオーバータイプ

フェイルオーバー タイプはより強力で柔軟性があります。このとき、制御の粒度は、選択またはセッションのいずれかのユーザー SQL の実行に基づいて設定できます。これを説明するために、小さな例を見てみましょう。

たとえば、ノード 2 で大規模なクエリが実行されていて、ノード 2 が突然クラッシュしたとします。実行中のクエリには、たとえば 10,000 件のデータ レコードがあり、障害が発生したときに 8,000 件のレコードが見つかった場合、残りの 2,000 件のレコードをどのように処理すればよいでしょうか。

最初の方法は select を使用することです。つまり、フェイルオーバーが完了し、残りの 2,000 件のレコードが引き続き返されます。もちろん、途中でコンテキストの切り替えが行われますが、これはユーザーには透過的です。

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

10g バージョンでは、ロード バランス + フェイルオーバーの構成は、次のように VIP 構成を使用して実現されます。

racdb=
(説明 =
(アドレス= (プロトコル= TCP)(ホスト=192.168.3.101)(ポート= 1521))
(アドレス= (プロトコル= TCP)(ホスト=192.168.3.201)(ポート= 1521))
(LOAD_BALANCE = はい)
(フェイルオーバー = オン)
(CONNECT_DATA =
(サーバー=専用)
(サービス名 = racdb)
(FAILOVER_MODE =
(タイプ=選択)
（方法 = 基本）
(再試行回数 = 30)
(遅延 = 5))))
SCAN-IP 11g のフェイルオーバーをさらに拡張する場合は、failover_mode と対応するタイプも設定する必要があります。
RACDB =
(説明 =
(アドレス = (プロトコル = TCP)(ホスト = rac-scan)(ポート = 1521))
(CONNECT_DATA =
(サーバー = 専用)
(サービス名 = RACDB)
）
）

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

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

この点、MySQL はいわゆる負荷分散をネイティブでサポートしていません。ミドルウェア プロキシの使用や継続的な分割など、フロントエンド業務を通じて転用できます。一定の粒度に達した後は、アーキテクチャ設計を通じてニーズを満たすことができます。ロジックベースのレプリケーションのため、拡張が容易です。1 つのマスターと複数のスレーブは非常に一般的であり、コストは高くありません。遅延はありますが、非常に低いため、ほとんどのインターネットビジネスのニーズを満たすことができます。

MHA 切り替えをトリガーする条件について、ネットワークの観点から見ると、次の赤い点は潜在的な危険です。ネットワークの中断もあれば、ネットワークの遅延もあります。障害が発生した場合、データを保護するか、安定したパフォーマンスを確保するかは、独自のニーズに基づいてカスタマイズできます。この観点から、データが失われる可能性があります。これは、強力な一貫性を備えたロスレスレプリケーションではありません。

全体的に、RAC は集中型の共有ソリューションです。ストレージ レベルでの共有に加えて、ネットワーク レベルでのマルチキャストは、実際にはノード間の通信コストを増加させます。したがって、RAC はネットワークに対して大きな要件を持っています。遅延が発生すると非常に危険であり、ブレイン スプリットが発生すると非常に厄介です。 MySQL MHA ソリューションは配布されています。大容量をサポートする環境では、ノード間の通信コストは比較的低くなります。ただし、データ アーキテクチャの観点から見ると、複製されたデータ配布方式であるため、ストレージは共有されませんが、ストレージ コストは RAC よりも高くなります (ストレージの価格ではなく、保存されるデータ量)。