Amazon RDS for MySQL および MariaDB に MariaDB MaxScale を使用して Binlog Server を設定する方法

Amazon RDS for MySQL および MariaDB に MariaDB MaxScale を使用して Binlog Server を設定する方法:

Amazon RDS for MySQL と Amazon RDS for MariaDB の主要機能の 1 つがリードレプリカを作成する機能です。AWS マネジメントコンソールまたは AWS CLI を使用して、1 つのマスターデータベースインスタンスについて、最大 5 つのレプリカを簡単に作成できます。Amazon RDS は、マスターのバックアップを作成し、バックアップをレプリカとしてリストアし、マスターとレプリカへのレプリケーションチャネルを確立する、といった作業すべてを処理します。Amazon RDS のレプリケーションを完全に自動化した処理は、マネージドレプリケーションと呼ばれます。

非標準のレプリケーショントポロジを求めている場合は、Binlog Server を使用できます。たとえば、レプリカが 5 つ以上必要な場合や、下流のアプリケーションにレプリケーションログレコードを転送する場合です。Binlog Server はレプリカとは違い、マスターのログレコードを使用せず、マスターと 1 つ以上のサブスクライバーの間にキャッシングレイヤーを提供します。今回の記事では、このアプローチを使用した場合の利点 (といくつかの制限) について説明します。MariaDB MaxScale と ノンマネージドレプリケーション を使用して、Amazon RDS for MySQL および MariaDB に Binglog Server をセットアップする作業を紹介します。

Amazon RDS for MySQL および MariaDB のマネージドレプリケーション

Amazon RDS のマネージドレプリケーションは、必ずバックアップが終了してから、マスターに適用される次のトランザクションを開始しますので、セットアップ中のデータのロスはありません。Amazon RDS はレプリケーションを継続的にモニターして調整を行います。たとえば、不正なトランザクションによってレプリケーションが中断した場合は、マスターまたはレプリカが機能停止してから、レプリケーションを適切に再開します (つまりマスターの自衛策)。

Amazon RDS for MySQL および MariaDB のノンマネージドレプリケーション

マネージドレプリケーションは、コンソールと Amazon RDS ウェブサービス API で提供されますが、ノンマネージドレプリケーションは、一連のストアドプロシージャで提供されます。この中には以下のものが含まれています。

rds_set_external_master – Amazon RDS for MySQL または MariaDB のインスタンスからマスターへのカスタムレプリケーション設定を行います。このマスターは Amazon RDS インスタンスあるいは外部の MySQL互換インスタンス (たとえば、Amazon EC2 で稼働している MySQL インスタンス) の可能性があります。このプロシージャは、MySQL のネイティブ CHANGE MASTER TO コマンドのラッパーと考えられます。
rds_set_external_master_gtid – ファイルベースの座標ではなく、グローバルトランザクション識別子 (GTID) ベースの座標を使用して、カスタムレプリケーションを設定する Amazon RDS for MariaDB のみのプロシージャ。
rds_reset_external_master – 前に mysql.rds_set_external_master で設定したカスタムレプリケーション設定を削除する。このプロシージャは、MySQL のネイティブ RESET SLAVE コマンドのラッパーと考えられます。
rds_start_replication – カスタムレプリケーションの設定完了後またはレプリケーション停止後に、レプリケーションを開始する。このプロシージャは、MySQL のネイティブ START SLAVE コマンドのラッパーと考えられます。
rds_stop_replication – マネージドまたはノンマネージドのいずれかのレプリケーションを停止します。このプロシージャは、MySQL のネイティブ STOP SLAVE コマンドのラッパーと考えられます。

Binlog Server の概要

MySQL および MariaDB のユーザーの中には、MariaDB MaxScale などのプロキシサーバーを使用して、自動での読み込みと書き込みの分割、スキーマベースシャーディング、変更データキャプチャなどの機能をうまく活用するユーザーもいます。提供されている別のユニークな機能としては、マスターとレプリカの中間のバイナリログキャッシュレイヤーの役割を果たす Binlog Server を作る機能があります。マスターは Binlog Server で稼働しているプロキシにバイナリログを送信し、次にレプリカがそのプロキシのバイナリログを読み込みます。

このオプションにはさまざまな利点があります。

バイナリログのレプリカへの送信には、プロキシとの通信が必要なだけなので、マスターの負荷が少なくなります。プロキシは順番にレプリカに送信します。
プロキシには、もともとマスターにあったバイナリログと全く同じものがあります。これらのログは、マスターやレプリカに影響することなく保存して分析できます。
Binglog Server プロキシによって、マスターとレプリカの依存関係が取り除かれるため、マスターのフェイルオーバーと別のマスターへの移動が簡単に自動化できます。

Booking.com の Jean-François Gagné は、Binlog Server の利点と、MaxScale を使用して、それをオンプレミス環境に設定する方法をさまざまなブログに投稿しています。

Amazon RDS に Binglog Server を設定する

MariaDB MaxScale と Amazon RDS ノンマネージドレプリケーションを使用して、Amazon RDS に Binglog Server を設定できます。Amazon RDS に一定の制限を加えると、オンプレミス環境と比べて Binlog Server の使用には制約があります。それでも、Amazon RDS for MySQL と Amazon RDS for MariaDB の両方にベーシックな設定をすることは可能です。

最初に、マスターとして使用する RDS インスタンスが必要となります。この設定では、まだレプリカがなく、マスターが新たに作成中であると仮定します。まず、ノンマネージドレプリケーションをサポートするバージョンを使用して、Amazon RDS for MySQL または MariaDB のインスタンスを作成します。これはメジャーバージョン 5.6 以降の Amazon RDS for MySQL インスタンスまたは Amazon RDS for MariaDB の任意のバージョンです。可能なら、最初はバックアップ保持有効のインスタンスは作成しないでください。その理由は、後にそのインスタンスが生成した最初のバイナリログが、Amazon RDS オートメーションによって自動的に削除されないということを確実にするためです。

試験設定では、jaime-binlog-server-master という名前の米国西部 (オレゴン) リージョンの MySQL 5.7.21 インスタンスに RDS を作成しました (デフォルトポート3306)。また、パラメータの変更が必要になる場合に備えて、自分のインスタンスに jaime-binlog-server-pg という名前のカスタムパラメータグループを作成しました。

binlog の保持の設定

RDS インスタンスを作成してから、SQL クライアントを使用した次のコマンドを実行することで、ホストのバイナリログの保持期間を延長することが可能になります。

call mysql.rds_set_configuration('binlog retention hours', 24);

このコマンドによって、バイナリログはローテーション後 24 時間、ホストに保持されることが確実になります。このコマンドを実行しなければ、ローテーション後約 5 分で、Amazon RDS オートメーションによってログはホストから削除されます。このコマンドを実行すると、AWS CLI またはコンソールを使用することで RDS インスタンスのバックアップの保持を有効にすることができます。バックアップの保持期間を有効にすると、バイナリログも可能になります。保持期間を延長したため、生成されたバイナリログは、延長した期間ホストに保持されます。これは後に、最初に生成されたログから、Binlog Server がログのダウンロードを開始するために必要です。

Binlog Server の作成

最初に Amazon EC2 インスタンスをセットアップすることで、Binlog Server を作成します。このインスタンスは、最初に作成した Amazon RDS マスターインスタンスにアクセスできます。これは EC2 インスタンスを、RDS インスタンスと同じ Virtual Private Cloud (VPC) に作成するということになります。または、RDS インスタンスと関連するセキュリティグループに CIDR IP 範囲を許可することもでき、これには EC2 インスタンスの IP アドレスが含まれています。

EC2 インスタンスに使用する Amazon Machine Image (AMI) は、ユーザーの選択に任されます。ただし、MaxScale ソフトウェアのインストールは、使用される Linux ディストリビューションによって異なります。試験設定では、Red Hat Enterprise Linux (RHEL) 7.4 – ami-223f945a を選択しました。

RHEL 7 ベースにして EC2 インスタンスを作成すると、MariaDB Package repository を使用して、MariaDB クライアントツールと共に、MaxScale を簡単にインストールできます。

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
yum install maxscale
yum install MariaDB-server

本記事の執筆時点では、MaxScale の最新バージョンは、バージョン 2.2.5 です。

MaxScale ユーザーの作成

MariaDB MaxScale には、MySQL インスタンスに接続して、そのインスタンスの他のユーザーやアーティファクトの詳細を調べるコマンドを実行できる特殊なユーザーが必要です。これは通常の Amazon RDS マスターまたは MaxScale だけの特殊なユーザーです。

試験設定では、EC2 ユーザーのホスト名と関連付けて maxscale ユーザーを作成し、MaxScale に必要な適切な権限を付与する一連のコマンドを実行しました。

CREATE USER 'maxscale'@'ec2-23-131-67-19.us-west-2.compute.amazonaws.com' IDENTIFIED BY 'F7XfBfJl'; 
GRANT SELECT ON mysql.user TO 'maxscale'@'ec2-23-131-67-19.us-west-2.compute.amazonaws.com'; 
GRANT SELECT ON mysql.db TO 'maxscale'@'ec2-23-131-67-19.us-west-2.compute.amazonaws.com'; 
GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'ec2-23-131-67-19.us-west-2.compute.amazonaws.com'; 
GRANT SHOW DATABASES ON *.* TO 'maxscale'@'ec2-23-131-67-19.us-west-2.compute.amazonaws.com';

さらに、MaxScale はユーザーとしてマスターに接続し、バイナリログをダウンロードするため、 REPLICATION SLAVE 権限を持つユーザーが必要です。通常、Amazon RDS マスターユーザーがこの権限を持っています。しかし万が一の場合には、admin という名前のマスターユーザーに明示的に権限を付与するために、次のコマンドを実行できます。

GRANT REPLICATION SLAVE ON *.* TO 'admin'@'%';

maxscale.cnf の設定

MaxScale では、通常 /etc/maxscale.cnf という名前の設定ファイルをコピーします。このファイルには、MaxScale で実行するサービスの種類とサービス固有のパラメータが定義されます。Binlog Server テンプレート設定ファイルは、この設定に含まれています。MaxScale を設定して Binlog Server として実行するには、テンプレートファイルを /etc/maxscale.cnf としてコピーします。

sudo cp /usr/share/maxscale/maxscale_binlogserver_template.cnf /etc/maxscale.cnf

次にこのファイルを編集して、次のように変更します。

user=repl を user=maxscale に passwd=slavepass を passwd=F7XfBfJl に (maxscale の user password に選択されたものであれば何でも) 変更します。
version_string=5.6.15-log を version_string=5.7.21-log に変更します。バージョンを表わす文字列は、MySQL または MariaDB の Amazon RDS のバージョンによって決まります。今回の場合、RDS インスタンスは MySQL 5.7.21 をベースにしていたので、6.15 を 5.7.21 で置き換えました。
router_options の文字列には、サーバー ID、マスターユーザー名、マスターユーザーパスワード、、mariadb10-compatibility=0、および filestem=mysql-bin-changelog を含む必要があります。
- サーバー ID については、SELECT @@server_id でクエリーした結果を記録することで、RDS インスタンスと同じサーバー ID を使用します。
- mariadb10-compatibility=0 が必要なのは、MariaDB 10.0 以降と同じ GTID フォーマットを使用しない MySQL インスタンスであるためです。
- filestem=mysql-bin-changelog により、MaxScale ではバイナリログに mysql-bin-changelog というプレフィックスを付けることが分かりますが、これが Amazon RDS の標準の命名規則です。たとえば、サーバー ID を 1961731445、マスターパスワードを qqnalh9u とすると、router_options 行は次のようになります。
  router_options=server-id=1961731445,user=admin,password=qqnalh9u,mariadb10-compatibility=0,filestem=mysql-bin-changelog
address=master.example.com を各自の RDS インスタンスのエンドポイントに変更します。今回の場合では、address=jaime-binlog-server-master.wzyowmbtiken.us-west-2.rds.amazonaws.com
[Binlog Listener] セクションでは、port=5306 を port=3306 など、 RDS for MySQL インスタンスに設定されたポートに変更します。

/etc/maxscale.cnf ファイル全体は、次のようになります。

# 
# Example maxscale.cnf for the Binlog Server. 
# 
# 
 
####################################################################### 
# MaxScale Global configuration. 
# 
# Valid options are: 
#       threads=<number of threads> 
[maxscale] 
threads=6 
 
# Other parameters. 
#log_messages=1 
#log_trace=1 
#log_debug=1 
#non_blocking_polls 
#poll_sleep 
 
 
####################################################################### 
# A series of service definitions 
# 
# Valid options are: 
#       type=service 
#       router=<name of router module> 
#       servers=<server name>,<server name>,... 
#       user=<User to fetch password information with> 
#       passwd=<Password of the user, plain text currently> 
#       version_string=<specific string for server handshake, 
#               default is the MariaDB embedded library version> 
#       router_options=<option[=value]>,<option[=value]>,... 
# 
 
####################################################################### 
# The MaxScale Binlog Server Service. 
# 
# The name of this service will be used as the directory name 
#   in the cache directory where the binlogs will be saved. 
# If this name is changed, it must be changed in the listener 
#   configuration below. 
[Binlog_Service] 
 
# type must be service 
# router must be binlogrouter 
type=service 
router=binlogrouter 
 
# servers should include a single name corresponding to the master 
#    where the Binlog Server will download its binlogs from. 
servers=master 
 
# user, password and version: see generic definition. 
# Note: user should have the following grants: 
#       SELECT ON mysql.user 
#       SELECT ON mysql.db 
#       SHOW DATABASES ON *.* 
user=maxscale 
passwd=F7XfBfJl 
version_string=5.7.21-log 
 
# The router_options set parameters to the binlogrouter: 
#    server-id= 
#       The server-id that MaxScale uses when it connects 
#       to the real master server.Again it will report 
#       the master's server-id to the slaves that connect 
#       to it. 
#    user= 
#       The user that MaxScale uses to log in to the real master. 
#       Note: user should have "REPLICATION SLAVE" grant. 
#    password= 
#       The password that MaxScale uses to log in to the real master. 
#    filestem= 
#       The prefix of the binlogs downloaded from master. 
router_options=server-id=1961731445,user=admin,password=qqnalh9u,mariadb10-compatibility=0,filestem=mysql-bin-changelog 
 
###################################################################### 
# Configuration of the master from which binlogs are downloaded. 
# 
[master] 
type=server 
address=jaime-binlog-server-master.wzyowmbtiken.us-west-2.rds.amazonaws.com 
port=3306 
protocol=MySQLBackend 
 
 
###################################################################### 
# Configuration of the listening service of the Binlog Server. 
# 
[Binlog Listener] 
type=listener 
service=Binlog_Service 
protocol=MySQLClient 
port=3306 
 
 
###################################################################### 
# Debug Service and Listener. 
# 
[Debug Service] 
type=service 
router=debugcli 
 
[Debug Listener] 
type=listener 
service=Debug Service 
protocol=telnetd 
address=localhost 
port=4442 
 
 
###################################################################### 
# CLI Service and Listener. 
# 
[CLI Service] 
type=service 
router=cli 
 
[CLI Listener] 
type=listener 
service=CLI Service 
protocol=maxscaled 
address=localhost 
socket=default 
 
 
# EOF.

master.ini の設定

デフォルトでは、バイナリログはMaxScale を実行している EC2 ホストの /var/lib/maxscale ディレクトリにダウンロードされます。もう一つのマスター固有の設定ファイルがこのディレクトリに必要で、MaxScale に CHANGE MASTER TO コマンドを発行し、RDS インスタンスでレプリケーションの設定をするために実行する必要があります。このファイルは master.ini という名前で、少なくとも中に master_host、master_port、master_user、および master_password のプロパティがあります。このプロパティには、Amazon RDS エンドポイント、ポート、マスターのユーザー名、マスターのユーザーパスワードをそれぞれ設定する必要があります。

たとえば master.ini ファイルは、試験設定では次のようになります。

[binlog_configuration] 
master_host=jaime-binlog-server-master.wzyowmbtiken.us-west-2.rds.amazonaws.com 
master_port=3306 
master_user=admin 
master_password=qqnalh9u

もう一つの方法として、MaxScale を master.ini ファイルなしで起動し、MaxScale のユーザーとしてプロキシに接続し、CHANGE MASTER TO コマンドを発行することで、ファイルを自動生成するということも可能です。これは長期間にわたって稼働していて、初期のバイナリログファイルがすでにホストにない、既存のマスターに接続する必要がある場合に便利です。そうでない場合は、明示的な master.ini をベースにした設定は、初期のバイナリログ (例、mysql-bin-changelog.000001) から開始することが前提になります。

MaxScale の起動

この時点で間違いなく MaxScale.を起動できます。まず、MaxScale が Amazon RDS インスタンスに Amazon RDS エンドポイントとポートを経由してMaxScale ユーザーとして接続できることを検証します。MariaDB クライアントツールが EC2 ホストにインストールされているはずなので、mysql client を実行して接続性を検証します。

たとえば、次のコマンドは私が接続性を検証するために実行したものです。

mysql -hjaime-binlog-server-replica. wzyowmbtiken.us-west-2.rds.amazonaws.com -umaxscale -p F7XfBfJl --port=3306

接続できれば、次のコマンドを使用して MaxScale を安全に起動できます。

sudo service maxscale start

MaxScale が実行中の時も、次のコマンドでステータスを確認できます。

sudo systemctl status maxscale.service

show services コマンドで maxadmin ユーティリティを実行し、Binlog_Service などのすべてのサービスのサマリーを取得することもできます

Binlog Server が適切に稼働しているとバイナリログが /var/lib/maxscale ディレクトリに蓄積していき、mysql-bin-changelog.000001 から処理が開始します (明示的な master.ini ファイルと仮定)。maxadmin のサービスサマリーの最初の数行は、次のような感じでしょう。

        Service:                             Binlog_Service 
        Router:                              binlogrouter 
        State:                               Started 
        Master connection DCB:               0x18f3850 
        Master connection state:             Binlog Dump 
        Binlog directory:                    /var/lib/maxscale

明示的な master.ini ファイルがなければ、MaxScale ユーザーとしてプロキシにに接続し、CHANGE MASTER TO コマンドを発行します。たとえば、ユーザーがバイナリログファイル mysql-bin-changelog.007076 の位置 4 からバイナリログのダウンロードの開始を求めている、ということに対応します。MaxScale を実行している EC2 では、MySQL クライアントを使用して、以前設定した MaxScale ユーザとして、ホストアドレス 127.0.0.1 に接続します。

mysql -h127.0.0.1 -umaxscale -pF7XfBfJl

次に、以下の CHANGE MASTER TO コマンドを発行します。

CHANGE MASTER TO MASTER_HOST = 'jaime-binlog-server-master.wzyowmbtiken.us-west-2.rds.amazonaws.com', MASTER_PORT = 3306, MASTER_USER = 'admin', MASTER_PASSWORD = 'qqnalh9u', MASTER_LOG_FILE = 'mysql-bin-changelog.007076', MASTER_LOG_POS = 4;

レプリカの追加

適切なパラメータで mysql.rds_set_external_master へのコールを発行すると、Binlog Server にレプリカを追加できます。レプリカの初期設定は、次の 2 つの方法で実施できます。

Amazon RDS マネージドレプリカを作成し、レプリケーションが完全に同期するまで待ち、rds_stop_replication をコールしてレプリケーションを停止します。SHOW SLAVE STATUS 出力の Relay_Master_Log_File と Exec_Master_Log_Pos 値を記録します。Read Replica を Promote し、それをマネージド Amazon RDS レプリカからノンマネージドに変換します。
標準の RDS インスタンスを作成し、mysqldump や AWS Database Migration Service (AWS DMS) などのツールを使用して、インスタンスをマスターから投入します。mysqldump を使用する場合、一貫性のあるデータのダンプを取るときは、マスターのバイナリログの位置を記録する必要があります。通常、これは mysqidump の一部として、--master-data=2 を指定することで実現できます。ただし、Amazon RDS for MySQL では、FLUSH TABLES の内部制限のために、これではうまくいきません。

いずれにせよ、最終的にレプリカを追加する場合は mysql.rds_set_external_master をコールします。MaxScale を実行している EC2 ホストのホストアドレスを、Amazon RDS マスターユーザーの資格情報、レプリケーション開始位置のバイナリログファイルの座標と共に受け渡します。

試験設定では、1 番目のバイナリログから開始して次のコマンドを発行します。

CALL mysql.rds_set_external_master ('ec2-23-131-67-19.us-west-2.compute.amazonaws.com', 3306, 'admin', 'qqnalh9u', 'mysql-bin-changelog.000001', 4, 0);

Amazon RDS Binlog Server の制限

MaxScale は Amazon RDS をサポートしていますが、Amazon 以外の RDS for MySQL インスタンスを実行するときと比べて、次のようないくつかの制限に注意してください。

Amazon RDS for MySQL および Amazon RDS for MariaDB で、log_slave_update パラメータを修正できます。このパラメータは、Amazon RDS for MySQL および MariaDB では常に使用可能です。
Multi-AZ や Binlog Server のバイナリログの削除など、MaxScale のまわりには Amazon RDS オートメーションはありません。こうしたロジックはすべて手動で操作する必要があります。
現時点では GTID ベースのレプリケーションのサポートはありません。Amazon RDS for MySQL は GTID ベースのレプリケーションをサポートしていませんが、これは問題ありません。Amazon RDS for MariaDB については、mysql.rds_set_external_master_gtid ストアドプロシージャの代わりに、rds_set_external_master ストアドプロシージャを使用する必要があります。

まとめ

Binlog Server は、マスターと 1 つ以上のレプリカの間の中間的なバイナリログのキャッシュレイヤーとして有用です。この記事では、こうしたアプローチを採用した場合の利点と制限について説明し、MariaDB MaxScale を使用して Binglog Server を設定する手順を紹介しました。Amazon RDS for MySQL および MariaDB において、レプリケーションプロセスのコントロールを向上できるのは、魅力的な選択肢です。

著者について

Jaime Lichauco は、Amazon Web Services の RDS チームのデータベースエンジニアです。

このブログを検索

IT音痴アラフィフおやじのストック記事倉庫