MariaDB MaxScale をデータベースプロキシとして導入する

MaxScaleをプロキシ層として配置する

MariaDB MaxScale アプリケーションとMariaDBサーバーの間に位置する独立したプロキシ層です。安定した運用を行うためには、設定、利用可能な機能、および既知の制限事項が、実際にインストールされているバージョンと常に一致している必要があります。MaxScale 25.10シリーズは、公式ドキュメント内で独自のリリースノートが掲載されています。

このアプリケーションは、データベースサーバーに直接接続するのではなく、MaxScaleのリスナーに接続します。この際、1つのサービスがアクセスロジックを統合し、ルーターがバックエンドを決定し、さらにフィルタがリクエストを転送する前に追加処理を行うことができます。データはMariaDBのバックエンド上に残ります。MaxScale自体がデータベースになるわけではありません。

この分離は、アプリケーション自体が、どのサーバーが現在どの役割を担っているかを把握する必要がない場合に特に役立ちます。データモデル、SQL、およびデータベースの運用に関する基礎については、以下の記事をご覧ください。 オープンソースデータベースとしてのMariaDB 適切な補完手段です。プロキシはサーバーアーキテクチャを補完しますが、データベースの権限や、レプリケーションおよび障害対策の仕組みに取って代わるものではありません。

時点では 接続ルーティング MaxScaleはセッションの確立時にターゲットを選択し、そのバックエンドが当該セッションを担当し続けます。 ステートメントルーティングでは、ルーターは個々のSQL文の内容に基づいて、それらを異なる方法で割り当てることができます。したがって、どの方式が適切かは、トランザクション、セッションの状態、およびアプリケーションが読み取りパスと書き込みパスを適切に分離できるかどうかに依存します。

A データベースプロキシ これは一律のパフォーマンス保証ではありません。ルーティングを一元化したり、アプリケーション間のロール切り替えを分離したり、適切な読み取りリクエストを分散させたりすることができます。 ただし、追加のネットワークノード、SQL分析、および具体的なバックエンドトポロジーは、その挙動に影響を与えます。したがって、耐負荷性と容量については、自社のバージョン、構成、および負荷条件下で検証する必要があります。

プライマリ・レプリカ・トポロジーの適切な監視

典型的なターゲットアーキテクチャは、書き込みを行うプライマリと、1つ以上の読み取り専用レプリカで構成されます。MaxScaleは、固定のDNS名の背後などにある、アプリケーションの唯一のデータベースエンドポイントです。 したがって、アプリケーションは個々のホストに直接接続することはなく、到達可能で適切なバックエンドの選択はプロキシ層内で行われます。

プライマリ・レプリカ・トポロジーの場合、モニターは以下を特定します mariadbmon バックエンドの状態を監視し、それらがプライマリかレプリカかの役割を識別します。ルーターは、この情報を宛先選択に利用できます。したがって、モニターは実際のレプリケーショントポロジーを把握できていなければなりません。誤った割り当て、レプリケートされていないデータ、あるいは不明確な役割は、ルーティング上の問題ではなく、運用上のリスクとなります。

ロールの識別と、その変更は区別する必要があります。適切な設定と権限があれば、mariadbmon はフェイルオーバー、計画的なスイッチオーバー、およびリジョインを管理できます。 スイッチオーバーとは、メンテナンスや運用を目的として意図的に準備されたロールの切り替えであり、フェイルオーバーは障害への対応です。どちらのプロセスも、明確なトポロジー、監視、アラート、および文書化されたインシデント対応または復旧プロセスを必要とします。

純粋な監視業務のみを行う場合、モニターアカウントは次の原則に従って設定すべきです。 最小特権 必要な権限のみが付与されます。現在のドキュメントでは、これを「REPLICA MONITOR」と呼んでいます。追加の権限は、有効化されている機能に応じて必要となります。例えば、ストレージ容量のチェックには「FILE」権限が必要であり、トポロジースキャンやクラスタ操作には、さらに特定の権限が個別に必要となります。これらに代わるものとして、一律のフルアクセス権は適用されません。

自動化を実施する前に、チームは、役割の切り替えを承認する担当者を誰にするか、レプリカの状態をどのように確認するか、そしてアプリケーションに障害をどのように通知するかを決定しておく必要があります。 MaxScaleは、認識された役割に基づいてルーティング先を調整できます。ただし、切り替えが技術的に許容されるかどうかは、データ、時間、および責任の範囲を定めた高可用性コンセプトによって決定されます。

SQLルーティングと一貫性境界の理解

ルーター readwritesplit 書き込み用のSQLステートメントをプライマリに転送し、適切な読み取りクエリをレプリカに分散させます。これにより、プライマリ・レプリカ群は、アプリケーションが各クエリを個別にサーバーに割り当てる必要なく、読み取り処理能力をより効率的に活用できるようになります。この際、選択の基準となるのは、モニターの役割情報です。

この割り当て方法では、標準的には、書き込みの直後に読み取りが行われた場合でも、新しい状態が反映されることは保証されません。 causal_reads デフォルトでは none. 例えば、あるアプリケーションが注文ステータスを書き込んだ後、別のクエリでそれを読み取ろうとした場合、レプリカは依然として以前の状態を返す可能性があります。意図的にプライマリの読み取りパスを指定したり、共通のトランザクションコンテキストを使用したりすることも有効な戦略ですが、それだけが唯一の手段というわけではありません。

のために 書き込みの読み取り 「Causal Reads」が有効になっている場合、readwritesplit はレプリカの遅延があっても、先行する書き込みを考慮に入れることができます。このモードは local 同じ接続の可視性を確保します。 global サービスによって保存されたGTIDの状態を、その接続全体にわたって維持します。ただし、読み取り操作のグローバルな「Happens-before」順序が保証されるのは、すべてのトランザクションが単一のGTIDドメイン内に収まっている場合に限られます。 universal クラスタのプライマリで観測されるトランザクションの状態を反映します。ただし、適用範囲が広くなるほど、同期処理の負荷が増大し、ひいてはレイテンシの増加につながる可能性があります。

Causal ReadsはGTID情報を用いて動作し、高速モード以外ではレプリケーションが完了するのを待ちます。同期処理が causal_reads_timeout – デフォルトでは10秒 –、readwritesplitはプライマリでクエリを実行しようとします。書き込み禁止のトランザクションでは、クエリをプライマリに移行できないため、代わりにタイムアウトがエラーとして返される場合があります。

高速モード fast, fast_global そして fast_universal レプリカを待たず、必要に応じてプライマリを使用します。プライマリにはタイムアウトが適用されません。そのため、書き込みが少なく、主に読み取りを行うワークロードに特に適しています。MaxScale 24.02 以降では、MaxScale が新しいバックエンド接続に必要なトラッキングを自動的に設定します。それ以前のバージョンでは、このために last_gtid に於いて session_track_system_variables すべてのバックエンドで。

オープンな読み書きトランザクション内では、readwritesplit は読み取りアクセスをプライマリに転送します。 これにより、同じトランザクション内のステートメントが、レプリケーションの状態が異なるバックエンドで実行されることを防ぎます。この保守的なルールは、トランザクションの境界を業務上適切に設定することや、レプリケーションの遅延を独自のアーキテクチャ上の制約として扱うことを免除するものではありません。

ストアドプロシージャ、UDFの呼び出し、およびマルチステートメントの場合も、意図的に慎重な判断が下されます。文書化された事例では、このようなクエリはプライマリにルーティングされます。 その理由は、それらの影響やコンテキストが、単純な読み取りクエリと同様に扱われるべきではないためです。したがって、SQLルーティングは単に「SELECT」という単語を検索するだけでなく、安全なセッションおよびセマンティクスの処理に関するルールに従って行われます。

専門的に選定された閾値として レプリカ・ラグ 特定の読み取り操作の結果のレプリカを除外することはできますが、一貫性要件の代わりにはなりません。 許容できる遅延の程度は、例えば、古いカタログエントリが許容されるか、あるいは確認されたばかりの支払いステータスが必ず表示されなければならないかといった点によって異なります。この判断は、アプリケーションロジックや運用契約において行われるべきものであり、一般的なプロキシの設定値で決めるべきものではありません。

Readwritesplit を安全に設定する

読み取り/書き込み分離構成は、バックエンド、モニター、サービス、リスナーそれぞれに対して個別のオブジェクト定義で構成されます。以下の抜粋はファイルの構造を示したものであり、そのまま本番環境で利用できるテンプレートではありません。 角括弧内の値は、決してパスワードではなく、運用環境のシークレット管理を通じて提供されるアカウントやシークレットへの参照です。モニターとサービスは、それぞれの異なるタスクに応じて、独自のアクセス情報を必要とします。

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

サーバーオブジェクトは、単にアクセス可能な MariaDB バックエンドを指すものであり、どのインスタンスがプライマリで、どのインスタンスがレプリカであるかは、モニターがトポロジーに基づいて判別します。 モニターアカウントは、ステータスおよびロールの照会に使用されます。これとは別のサービスアカウントは、クライアントの認証および認可に必要なユーザー情報や権限情報をバックエンドから取得するために使用されます。どちらのアカウントも、それぞれの役割について文書化されている権限のみを必要とします。 ロールの識別 およびユーザー情報の読み込みは、別々のタスクです。

この例のプレースホルダーは、デプロイ時に保護されたデプロイ経路を通じて解決される必要があります。これらは、そのままの設定値として意図されたものではありません。平文のパスワード、実際の証明書パス、または検証されていない権限パッケージは、自由に読み取れるファイルやリポジトリに含めてはいけません。 MaxScaleは、MariaDBプロトコル接続に関して、システムテーブルから関連するユーザーアカウントと権限を内部的に管理しています。アカウントや権限が変更された場合、古い情報があるとログインや認証に支障をきたす可能性があります。

そのため、本番環境への移行前には、リスナーポート、ネットワークパス、ユーザー同期、および実際のルーター割り当てについて、個別に確認する必要があります。 また、モニターによる自動介入も、この最小構成には暗黙的に含まれていません。フェイルオーバー、スイッチオーバー、またはリジョイン機能には、追加の設定と、テスト済みの運用コンセプトが必要です。一見簡潔に見える設定であっても、シークレット管理やバックエンドトポロジの検証に代わるものではありません。

用途別にルーターの機種を比較する

ルーターの選択は、単に存在するレプリカの数だけでなく、アプリケーションの挙動に基づいて行われます。直接接続は構成をシンプルに保ちますが、宛先の切り替えや役割の認識はアプリケーションに委ねられます。2つの分離されたエンドポイントと readconnroute アプリケーションが意図的に読み取りおよび書き込み接続を自ら管理する場合に適しています。 ステートメントルーティング readwritesplit は、セッションを SQL に基づいてプライマリまたはレプリカにルーティングする場合に有用です。

readconnroute は、接続確立時に宛先サーバーを評価し、その後の各 SQL ステートメントを分析することはありません。 選択されたバックエンドに障害が発生すると、セッションは終了します。ルーターは自動的に別のサーバーに接続し直しません。これは、明確に区切られた短命な読み取り接続の場合には理にかなっていることが多々ありますが、ステートフルなアプリケーション処理には不向きな場合があります。

特に注意が必要なのは、読み取り専用エンドポイントとして設計されたサービスで、 router_options=slave。このオプションはレプリカ役のサーバーを優先しますが、すべてのレプリカがダウンし、プライマリが利用可能な場合は、readconnrouteはプライマリにフォールバックする可能性があります。また、このオプションは書き込み保護を適用しません。アプリケーションは読み取り専用のSQLのみを送信するか、追加のReadOnlyフィルターを使用して書き込みアクセスを阻止する必要があります。 したがって、ルーティング先やロールの優先順位は、権限の制限でもなければ、制限的なデータベース権限の代わりにもなりません。

一方、readwritesplitはアプリケーションコードにおけるターゲットの決定を削減しますが、セマンティクスの厳密な検証が必要となります。適切な読み取り操作はレプリカに分散させることができ、書き込み操作はプライマリに送信されます。 厳格な最新性要件が求められる処理においては、書き込み後のクエリがレプリケートされたデータを待機してもよいか、それとも意図的にプライマリを使用しなければならないかが、依然として決定的な要素となります。

会議、在庫、切り替えの計画

データベースセッションには、単一のクエリ以上のものが含まれます。 SET, USE, CHANGE USER また、プリペアードステートメント操作はコンテキストを変更します。readwritesplit は、関連するセッションコマンドを候補となるターゲットサーバーにレプリケートし、後でルーティングされたステートメントが適切なセッション状態の下で実行できるようにします。 この点が、ルーターを単純なTCPロードバランシングとは区別する点ですが、すべての特殊なケースの制限が解消されるわけではありません。

一時テーブルに対するプリペアードステートメントの場合、この制限は特に重要です。プライマリでそのようなステートメントがプリペアされると、レプリカでは必ずしもそれを実行できるとは限りません。したがって、アプリケーションでは、一時オブジェクト、プリペアードステートメント、およびトランザクションの流れについて、所定のルーティングモデルを用いてテストを行う必要があります。 セッションの状態 これは単なる付帯条件ではなく、SQLの分散が業務上および技術的に適切かどうかを決定づける要素である。

読み取り負荷の高い用途の場合、チームは、専門的に定められたレイの閾値をレプリカの除外基準として定義することができます。それだけで max_replication_lag ただし、レプリカへの以前の書き込みがすでに反映されていることを保証するものではありません。重要な後続の読み取りについては、処理の流れに応じて、意図的なプライマリパス、共通の書き込みコンテキスト、または有効化された因果関係に基づく読み取りが検討されます。

Causal Readsでは、適用範囲を意図的に選択する必要があります。 local 接続詞内の因果関係を維持する。 global サービス全体で保存されたGTIDの値を参照しますが、すべてのトランザクションが単一のGTIDドメイン内にある場合にのみ、読み取り操作のグローバルな「Happens-before」順序を保証します。 universal クラスタのプライマリで観測されるトランザクションの状態を考慮します。非高速モードではGTIDを使用して同期を行います。設定されたタイムアウト内にレプリカが追いつかない場合、トランザクションモードが許容する限り、クエリは原則としてプライマリ上で再実行されます。

この機能はバージョンによって分類されます。MaxScale 24.02 以降、MaxScale は以下の機能を追加しました。 last_gtid 新しいバックエンド接続については自身で設定する必要があります。以前のバージョンでは、 session_track_system_variables MariaDBのバックエンドで適切に設定されている必要があります。高速モードでは待ち時間を回避できますが、レプリカがまだ追いついていない場合、読み取りがプライマリにリダイレクトされる可能性があるため、書き込み負荷の高いワークロードには一律には適していません。

計画的なスイッチオーバーと自動フェイルオーバーも、別個に扱う必要があります。スイッチオーバーでは、ロールの切り替えが制御された形で準備されますが、フェイルオーバーでは、運用側が障害状態に反応することになります。 mariadbmonはロールやバックエンドの状態を監視でき、適切に設定されていれば、これらのプロセスをサポートすることができます。その際、レプリケートされたデータ状態、明確なトポロジー、アラート機能、およびインシデント対応プロセスが前提条件となります。

MaxScale 25.10 では、 discover-replicas 現在のプライマリに直接レプリケートしているサーバーを検出し、それらをMonitorおよびMaxScaleに追加します。この機能は、構成の同期とは互換性がありません。 したがって、この機能を使用する前に、チームはトポロジの変更を自動的に検出するか、それとも同期された構成によって制御するかを決定する必要があります。この枠組みでは、その両方を同時に実施することは想定されていません。

TLS、権限、およびフィルタのセキュリティ確保

MaxScale では、TLS を 2 つの別々の経路で設定する必要があります。1 つはアプリケーションからリスナーへの経路、もう 1 つはプロキシから MariaDB バックエンドへの経路です。両方の接続には、それぞれ独自の暗号化および証明書検証の設定が必要です。クライアント側の経路が保護されていても、下流の通信が自動的に暗号化されるわけではありません。 したがって、設定では、両方の区間におけるセキュリティ要件と信頼の連鎖を反映させる必要があります。

TLSが有効になっています ssl=true 各リスナーまたはサーバーの設定における暗号化。クライアントがサーバー証明書を要求する場合、リスナーには証明書と秘密鍵が必要となります。以下の権限を持つアカウント： REQUIRE SSL TLS を使用しないリスナー経由ではログインできません。証明書ファイルや鍵は、自由に閲覧可能なサンプル設定やリポジトリの設定ではなく、保護された運用環境に配置する必要があります。

また 権利の概念 バックエンドにおいては、依然として重要な点があります。MaxScaleは接続を仲介しますが、正確なデータベースアカウントに取って代わるものではありません。サービスアカウントには、その役割に必要な権限のみが付与されます。 MaxScaleは、ログインおよび認証において、MariaDBのシステムテーブルにあるユーザーアカウントと権限に依存しています。したがって、これらのアカウントへの変更は、内部のユーザー管理システムで速やかに反映される必要があります。

ファイアウォールフィルタは、学習済みまたは定義済みのルールに基づいて、SQLを転送する前に検証することができます。このフィルタには、アイドルモード、学習モード、監視モード、強制モードがあり、強制モードでは、設定に応じて許可されていないステートメントパターンに対してエラーを返すか、接続を切断します。 フィルタが通常のクエリをブロックしないようにするため、学習フェーズでは、代表的な許可されたアプリケーションの処理フローを網羅する必要があります。

このフィルターは、想定されるSQLパターンに対する追加のチェック層であり、権限の代替となるものではありません。 このフィルターは、そのルールに基づいて自身に送信されるクエリのみを評価するものであるため、厳格なデータベース権限、保護されたアクセス情報、および検証済みのアプリケーションコードは依然として必要です。他のフィルターに関する記述については、それぞれのドキュメントに基づいて個別に確認する必要があります。

設定とエラーを体系的に確認する

接続やルーティングのエラーが発生した場合は、当て推量で変更を加えるのではなく、決まった順序でチェックを行うことが有効です。まず、モニターのステータスを確認してください。すべてのバックエンドに到達できるか、プライマリとレプリカの役割が想定通りに認識されているかを確認します。その上で初めて、ルーターの判断を適切に評価することができます。 誤って認識されたノードや到達不能なノードは、単なるリスナーの問題ではありません。

次に、リスナーとTLSについて確認します。ポート、プロトコル、証明書、鍵、および使用されるアカウントの要件が一致している必要があります。 続いて、ユーザーアカウント管理が最新のバックエンドアカウントと権限を認識しているか確認してください。特にユーザーや権限に変更を加えた後、アカウントデータが古くなっている場合、MariaDB上では正しく設定されていてもログインできなくなることがあります。

次に、サービス、ルーター、および割り当てられたサーバーを割り当てます。読み取り/書き込み分割では、さらにレプリカ遅延、 causal_reads およびアプリケーションのトランザクション制限をチェックリストに追加します。「Causal Reads」が有効になっていない場合、必要な書き込みコンテキスト外でのレプリカに対する読み取り操作では、古い状態が返される可能性があります。ラグ制限値だけでは、以前の書き込みの可視性が保証されるわけではありません。

さらに、1つの 設定ソース 確定。MaxScaleは実行時に変更内容を永続化できます。再起動時には、永続化された設定が静的ファイルを上書きします。チームの一部がファイルを編集し、一部が maxctrl 使用する場合、当該実行時設定の変更手順、レビュー、およびバックアップについては、必ず文書化しなければならない。

スキーマ変更のためのメンテナンスウィンドウは、独立した運用領域として扱う必要があります。依存関係、ロック挙動、レプリケーションについては事前に確認する必要があり、プロキシのせいにすることはできません。大規模なMariaDBテーブルに対する制御された変更を計画する際には、以下の記事が参考になります。 ダウンタイムなしのスキーマ変更 補足的なコンテキスト。MaxScaleはその後、バックエンドのロールに基づいて接続とルーティングを再び制御できますが、データベースのDDL戦略は実行しません。

警告：ロール、証明書、ユーザー権限、ルーティングの変更については、まず同様の環境で検証を行う必要があります。 本番環境での変更作業には、リセット手順、アプリケーションエラーの監視、および明確な責任分担が含まれます。これにより、障害がプロキシ設定、バックエンド、あるいはクライアントの動作のいずれに起因するかを区別できるようになります。

MaxScaleを適切に活用するか、あるいは使用しないか

ルーティング、フェイルオーバー、SQLフィルタリングの要件がない単一のMariaDBサーバーの場合、直接接続の方が通常は運用が簡単です。ただし、その場合は、アプリケーション側が後で宛先を変更する処理を自ら行う必要があります。 MaxScaleは、追加のエンドポイントが、ロール切り替えの処理、アクセスのフィルタリング、レプリカへの読み取りの制御された分散といった具体的なタスクを果たす場合に、導入する価値があります。

アプリケーションが読み取りおよび書き込みのパスを意図的に選択できる場合、 readconnroute 多くの場合、理解できる。このルーターは接続確立時にバックエンドを選択するが、すべてのSQL文を解析するわけではなく、中断されたセッションを別のサーバーに移行することもない。 router_options=slave レプリカが優先されます。すべてのレプリカがダウンし、プライマリがまだ利用可能な場合、ルーターはプライマリを使用できます。また、このオプションを有効にしても、エンドポイントが読み取り専用になるわけではありません。読み取り専用にするには、適切なReadOnlyフィルター、制限的なバックエンド権限、または厳格に管理されたアプリケーションSQLが必要です。

ORMおよびトランザクションモデルが適合するプライマリ・レプリカ・ワークロードについては、 readwritesplit このアプリケーションでは、ステートメントごとにSQLのターゲット選択を行います。デフォルト設定では causal_reads=none ただし、レプリケーションの遅延は依然として顕在化する。クリティカルな書き込みの後、アプリケーションはプライマリ読み取りパスまたは適切な共有トランザクションコンテキストを使用できる。あるいは、必要な可視性範囲に合わせて因果読み取りを個別に設定することも可能である。

Causal Readsでは、同一セッション内での可視性、サービスによって管理されるグローバルGTIDの状態、およびプライマリで観測されるクラスタの状態を区別しています。 local 同じ接続に適用されます。において global Reads のグローバルな「Happens-before」順序が保証されるのは、すべてのトランザクションが単一の GTID ドメインに属している場合に限られます。したがって、このモードを、サービス全体にわたる無制限の一貫性保証として一律に解釈してはなりません。 universal 読み取り処理の前に、プライマリの観測可能な状態を確認します。同期モードでは追加の待ち時間が生じる可能性があります。高速なバリエーションでは待機を行いませんが、書き込み処理においてプライマリへの負荷をより大きくシフトさせる可能性があります。

境界ケースについては、導入前に実際のドライバーとデータモデルを用いた的を絞ったテストを行う必要があります。 プライマリ側で準備が行われる場合、一時テーブルやそれに基づいて作成されたステートメントは、レプリカでは利用できない可能性があります。また、ストアドプロシージャ、UDFの呼び出し、マルチステートメント、およびセッションの状態も、ルーターがプライマリへ保守的にルーティングするかどうかを左右します。

トランザクション・リプレイは、トランザクションの損失がないことを保証するものではありません。接続が切断された場合、 COMMIT コミットがすでに成功したかどうかは、未確定のままにしておいても構いません。リスクの高いリプレイ設定では、書き込み操作が二重に実行される可能性があります。サーバーに依存する結果、例えば NOW() 或いは @@server_id さらに、チェックサムの不一致を引き起こす可能性もあります。したがって、その導入については、一貫性の要件、エラーの発生プロセス、および書き込みの再現性に基づいて評価し、一律的な性能保証に基づいて判断してはなりません。