以前のブログでは、データベースフェイルオーバーが必要な理由を正当化し、フェイルオーバーメカニズムがどのように機能するかを説明しました。 MySQLデータベースにフェイルオーバーメカニズムを設定する必要がある理由について質問がある場合に備えて、これを共有します。その場合は、以前のブログ投稿をお読みください。
フェイルオーバーを自動的に管理するためにMySQLまたはMariaDBを使用する利点は、環境で使用および実装できるツールが利用できることです。オープンソースからエンタープライズグレードのソリューションまで。ほとんどのツールはフェイルオーバー対応であるだけでなく、MySQLデータベースクラスターにより多くの管理機能を提供できるスイッチオーバー、監視、高度な機能などの他の機能もあります。以下では、使用できる最も一般的なものについて説明します。
MHA（マスター高可用性）の使用
MHAでこのトピックを取り上げ、最も一般的な問題とその修正方法について説明しました。また、MHAをMRMまたはMaxScaleと比較しました。
高可用性のためにMHAを設定するのは簡単ではないかもしれませんが、フェイルオーバーをカスタマイズするために定義できる調整可能なパラメーターがあるため、効率的で柔軟性があります。 MHAはテストされ、使用されています。しかし、テクノロジーが進歩するにつれて、MHAはMariaDBのGTIDをサポートしておらず、過去2、3年間は更新をプッシュしていないため、遅れをとっています。
masterha_managerスクリプトを実行することにより、
masterha_manager --conf=/etc/app1.cnf[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1no_masterやcandidate_masterなどのパラメータは、ホワイトリストに登録するノードをターゲットマスターに設定し、マスターにしたくないノードを設定するために重要です。
設定すると、プライマリまたはマスターで障害が発生した場合に備えて、MySQLデータベースをフェイルオーバーする準備が整います。スクリプトmasterha_managerは、フェイルオーバー（自動または手動）を管理し、フェイルオーバーのタイミングと場所を決定し、差動リレーログを適用するための候補マスターの昇格中にスレーブの回復を管理します。マスターデータベースが停止した場合、MHAマネージャーはMHAノードエージェントと調整します。これは、マスターからの最新のbinlogイベントがないスレーブに差分リレーログを適用するためです。
MHAノードエージェントの機能と関連するスクリプトを確認してください。基本的には、フェイルオーバーが発生したときにMHAマネージャーが呼び出すスクリプトです。 binlogイベントを含む最新のスレーブを検索し、scpを使用してスレーブから欠落しているイベントをコピーし、それらを自分自身に適用するときに、MHAマネージャーからの委任を待ちます。前述のように、リレーログの適用、リレーログのパージ、またはバイナリログの保存を行います。
調整可能なパラメーターとフェイルオーバー管理をカスタマイズする方法について詳しく知りたい場合は、MHAのパラメーターwikiページを確認してください。
Orchestratorは、MySQLおよびMariaDBの高可用性およびレプリケーション管理ツールです。これは、ApacheLicenseバージョン2.0の条件の下でShlomiNoachによってリリースされます。これはオープンソースソフトウェアであり、自動フェイルオーバーを処理しますが、リカバリや自動フェイルオーバー以外に、MySQL/MariaDBデータベースを管理するためにカスタマイズまたは実行できることがたくさんあります。
Orchestratorのインストールは簡単または簡単です。ターゲット環境に必要な特定のパッケージをダウンロードすると、Orchestratorによって監視されるクラスターとノードを登録する準備が整います。これは、管理が非常に簡単なUIを提供しますが、フェイルオーバー管理を実現するために使用できる調整可能なパラメーターまたはコマンドのセットが多数あります。
最終的にセットアップが完了し、プライマリノードまたはマスターノードを追加してクラスターを登録すると、次のコマンドで実行できると考えてください。
$ orchestrator -c discover -i pupnode21:3306
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: pupnode21
2021-01-07 12:32:31 DEBUG Cache hostname resolve pupnode21 as pupnode21
2021-01-07 12:32:31 DEBUG Connected to orchestrator backend: orchestrator:[email protected](127.0.0.1:3306)/orchestrator?timeout=1s
2021-01-07 12:32:31 DEBUG Orchestrator pool SetMaxOpenConns: 128
2021-01-07 12:32:31 DEBUG Initializing orchestrator
2021-01-07 12:32:31 INFO Connecting to backend 127.0.0.1:3306: maxConnections: 128, maxIdleConns: 32
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.222
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.222 as 192.168.40.222
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.223
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.223 as 192.168.40.223
pupnode21:3306これで、クラスターが追加されました。
プライマリノードに障害が発生した場合（ハードウェア障害またはクラッシュが発生した場合）、Orchestratorはプライマリノードまたはマスターノードとして昇格する最も高度なノードを検出して見つけます。
これで、プライマリがダウンしている間、クラスターに2つのノードが残っています。 。
$ orchestrator-client -c topology -i pupnode21:3306
pupnode21:3306 [unknown,invalid,10.3.27-MariaDB-log,rw,ROW,>>,downtimed]
$ orchestrator-client -c topology -i pupnode22:3306
pupnode22:3306 [0s,ok,10.3.27-MariaDB-log,rw,ROW,>>]
+ pupnode23:3306 [0s,ok,10.3.27-MariaDB-log,ro,ROW,>>,GTID]MaxScaleの使用
MariaDB MaxScaleは、データベースロードバランサーとしてサポートされています。何年にもわたって、MaxScaleは成長し、成熟し、いくつかの豊富な機能で拡張され、自動フェイルオーバーが含まれています。 MariaDB MaxScale 2.2がリリースされて以来、レプリケーションクラスターのフェールオーバー管理を含むいくつかの新機能が導入されています。 MaxScaleフェイルオーバーメカニズムに関する以前のブログを読むことができます。
MaxScaleの使用はBSLで行われますが、ソフトウェアは無料で入手できますが、少なくともMariaDBでサービスを購入する必要があります。適切ではないかもしれませんが、MariaDBエンタープライズサービスを取得した場合、フェイルオーバー管理やその他の機能が必要な場合、これは大きな利点になります。
MaxScaleのインストールは簡単ですが、必要な構成のセットアップとそのパラメーターの定義は簡単ではなく、ソフトウェアを理解する必要があります。それらの構成ガイドを参照できます。
迅速かつ迅速な展開のために、ClusterControlを使用して既存のMySQL/MariaDB環境にMaxScaleをインストールできます。
インストール後、ホストをMaxScale IPまたはホスト名と読み取り/書き込みポートにポイントすることで、Moodleデータベースのセットアップを行うことができます。たとえば、
どのポート4008が、サービスリスナーの読み取り/書き込みです。たとえば、MaxScaleの次のサービスとリスナーの構成を次に示します。
$ cat maxscale.cnf.d/rw-listener.cnf
[rw-listener]
type=listener
protocol=mariadbclient
service=rw-service
address=0.0.0.0
port=4008
authenticator=MySQLAuth
$ cat maxscale.cnf.d/rw-service.cnf
[rw-service]
type=service
servers=DB_123,DB_122,DB_124
router=readwritesplit
user=maxscale_adm
password=42BBD2A4DC1BF9BE05C41A71DEEBDB70
max_slave_connections=100%
max_sescmd_history=15000000
causal_reads=true
causal_reads_timeout=10
transaction_replay=true
transaction_replay_max_size=32Mi
delayed_retry=true
master_reconnection=true
max_connections=0
connection_timeout=0
use_sql_variables_in=master
master_accept_reads=true
disable_sescmd_history=falseモニター構成中に、自動フェイルオーバーを有効にすることを忘れないでください。また、オンラインに戻ったときに前のマスターが自動再参加に失敗する場合は、自動再参加も有効にする必要があります。このようになります
$ egrep -r 'auto|^\[' maxscale.cnf.d/replication_monitor.cnf
[replication_monitor]
auto_failover=true
auto_rejoin=1私が述べた変数は、本番環境での使用を目的としたものではなく、このブログ投稿とテスト目的のみを目的としていることに注意してください。 MaxScaleの良い点は、プライマリまたはマスターがダウンすると、MaxScaleは、マスターの役割を果たすための理想的または最良の候補を促進するのに十分なほど賢いことです。したがって、マスターがダウンした後は、MaxScaleノードのホスト/ IPとそのポートをエンドポイントとして使用しているため、IPとポートを変更する必要はありません。たとえば、
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘192.168.40.221を指すノードDB_123が現在のマスターです。ノードDB_123を終了すると、MaxScaleがトリガーされてフェイルオーバーが実行され、次のようになります。
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Down │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘その間、MaxScaleがプロモートされた最新のマスターを指しているため、Moodleデータベースはまだ稼働しています。
$ mysql -hmaxscale.local.domain -umoodleuser -pmoodlepassword -P4008
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.3.27-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> select @@hostname;
+------------+
| @@hostname |
+------------+
| 192.168.40.222 |
+------------+
1 row in set (0.001 sec)ClusterControlの使用
ClusterControlは無料でダウンロードでき、Community、Advance、およびEnterpriseのライセンスを提供します。自動フェイルオーバーは、AdvanceおよびEnterpriseでのみ使用できます。自動フェイルオーバーは、障害が発生したクラスターまたは障害が発生したノードを回復しようとする自動回復機能でカバーされています。これを実行する方法の詳細については、以前の投稿「ClusterControlが自動データベースリカバリとフェイルオーバーを実行する方法」を確認してください。それは非常に便利で使いやすい調整可能なパラメータを提供します。 ClusterControlを使用してデータベースフェイルオーバーを自動化する方法に関する以前の投稿もお読みください。
Moodleデータベースの自動フェイルオーバーを管理するには、データベースバックエンドとインターフェイスするMoodleアプリケーションクライアントのエンドポイントとして、少なくとも仮想IP（VIP）が必要です。これを行うには、その上にHAProxy（またはProxySQL-ロードバランサーの選択によって異なります）を使用してKeepalivedをデプロイできます。この場合、Moodleデータベースエンドポイントは仮想IPを指します。仮想IPは、MaxScaleをセットアップしたときに示したのと同じように、展開後に基本的にKeepalivedによって割り当てられます。方法については、このブログを確認することもできます。
上記のように、調整可能なパラメーターを使用できます。これらのパラメーターは、ClusterControlホストにある/etc/cmon.d/cmon_
- Replication_check_binlog_filter_bf_failover
- Replication_check_external_bf_failover
- Replication_failed_reslave_failover_script
- Replication_failover_blacklist
- Replication_failover_events
- Replication_failover_wait_to_apply_timeout
- Replication_failover_whitelist
- Replication_onfail_failover_script
- Replication_post_failover_script
- Replication_post_unsuccessful_failover_script
- Replication_pre_failover_script
- replication_skip_apply_missing_txs
- replication_stop_on_error
ClusterControlは、フェイルオーバーを管理する際に非常に柔軟性があるため、フェイルオーバー前またはフェイルオーバー後のタスクを実行できます。
Moodle用のMySQLデータベースのフェイルオーバーを設定して自動的に管理する場合、他にも優れた選択肢があります。それはあなたの予算とあなたがおそらくお金を使わなければならないものに依存します。オープンソースのものを使用するには専門知識が必要であり、コミュニティ以外の支援が必要なときに実行できるサポートがないため、慣れるために複数のテストが必要です。エンタープライズソリューションでは、価格がかかりますが、時間のかかる作業を減らすことができるため、サポートと使いやすさが提供されます。フェイルオーバーが誤って使用された場合、適切に処理および管理されていないと、データベースに損害を与える可能性があることに注意してください。より重要なことと、Moodleデータベースのフェイルオーバーを管理するために利用しているソリューションをどのように活用できるかに焦点を当ててください。