スマートスタイル TECH BLOG

バイナリログ中継サーバ “Ripple” を使ってみた

“Ripple”とは

Rippleは、Googleの Pavel Ivanov 氏が開発したMySQLレプリケーションの中継を行う中間サーバです。Apache-2.0ライセンスで公開されています。

Ripple は通常のレプリケーションスレーブと同様に、マスタに接続してバイナリログを読み取ります。ただし、テーブルデータは保持しないためバイナリログのイベントは実行せず、バイナリログをダウンロードしてローカル上に保存だけ行います。

スレーブは Ripple が保持するバイナリログを読み取ってレプリケーションを実行できます。つまり、「マスタ → Ripple → スレーブ」というトポロジーが可能となります。なお、今のところはGTIDレプリケーション限定のようです。

※ MySQLだけでなくMariaDBにも対応しているようです
※ ちなみに”Ripple”は日本語で「さざ波」という意味です

Rippleの用途

Ripple のユースケースとして考えられるのは以下の通りです。

+ 既存のマスタ/スレーブの中継

上記の通り、Ripple は既存のマスタ~スレーブのレプリケーションの間に入って通信を中継できます。
この時、マスタではバイナリログの読込および転送が不要となるため、負荷軽減が期待できます。

※ Blackholeストレージエンジンと似たような役割です

+ バイナリログのバックアップ(Binlog Server)

バイナリログはレプリケーションだけでなく、PITR(ポイント・イン・タイム・リカバリ)でも使用されるなど、かなり重要度の高いファイルです。そのため、ディスクの物理障害などでバイナリログファイル自体の参照ができなくなった場合、かなり困難な局面となってしまいます。
そこで、Ripple を活用して別サーバにバイナリログのバックアップを用意しておけば、最悪の事態を回避することができます。

検証

百聞は一見に如かず、ということでRippleを実際に使ってみました。
今回は以下のような検証環境を用意しました。サーバスペックは全て共通(2 vCPU, 4G MEM)にしています。

ホスト名 IPアドレス OS 用途
master 192.168.30.10 CentOS 7.4 MySQLマスタ
slave1 192.168.30.20 CentOS 7.4 MySQLスレーブ
slave2 192.168.30.30 CentOS 7.4 MySQLスレーブ2
middle 192.168.30.40 Ubuntu 18.10 Ripple

1. MySQL(マスタ)のインストール

まずは、master に MySQL8.0 をインストールします。

バイナリログとGTIDを有効にした状態でMySQLを起動します。

2. MySQL(スレーブ)のインストール

次にslave1/slave2 に MySQL8.0 をインストールします。

バイナリログとGTIDを有効にした状態でMySQLを起動します。

3. Rippleのインストール

middle サーバに Ripple をセットアップします。インストール手順はGitHubのページに載っていますが、Ubuntu 18.10を想定したコマンドになっています。そのため、同サーバのみ Ubuntu 18.10 で試します。

※ 試しにCentOS7.4環境でビルドしようとしましたが、上手くいきませんでした
※ gitコマンドのバージョンが 1.8.5 以降でないとビルド時にエラーが発生します

4. MySQL-clientのインストール

Rippleがマスタに接続するために、MySQL-clientを使用します。そのため、middleサーバにMySQL8.0の client のみインストールします。

5. Rippleのセットアップ

早速、Rippleを起動してみましょう。主要なオプションは以下の通りで、基本的にはCHANGE MASTERコマンドを実行する時と同様です。

オプション 説明
-ripple_datadir Rippleがバイナリログを保存するディレクトリのパス
-ripple_master_address マスタのIPアドレス
-ripple_master_user レプリケーションユーザのユーザ名
-ripple_master_password レプリケーションユーザのパスワード
-ripple_master_port Rippleがマスタに接続する時に使用するポート(マスタのmysqldが稼働するポート)
-ripple_server_ports Ripple自体が稼働するポート(スレーブが参照するポート)
-ripple_server_address bindするアドレス。デフォルトは”localhost”なので、外部からの接続を受け付けない
-ripple_purge_expire_logs_days バイナリログの保持期間(expire_logs_days変数と同じ)
-ripple_max_binlog_size Rippleが保持するバイナリログの最大サイズ(max_binlog_size変数と同じ)
-ripple_semi_sync_slave_enabled 準同期レプリケーションを利用している場合は”true”にする

これでRippleが正しく起動できました。

6. スレーブの接続

MySQLスレーブをRippleに接続して、レプリケーションを構築してみます。

ベンチマーク

この状態で、sysbenchを使った簡単なベンチマークを実施してみます。
masterサーバのローカル上で実行しましょう。

次に、slave1のレプリケーションとRippleを停止して、slave2から通常のレプリケーションを設定します。

その後、全く同じベンチマークを実行します。

ベンチマーク結果を比べてみます。

Rippleを利用した方がバイナリログに関連する負荷が下がるためsysbenchのスコアは上がると予想していましたが、結果的には逆にスコアが下がってしまいました。

まとめ

個人的な感想としては、レプリケーションを中継する役割よりもバイナリログをバックアップする使い方の方が便利そうです。特にサーバ台数が多い大規模環境などでは、バイナリログを救出できないディスク障害などが発生する可能性も高まるため、いざという時の安全策として重宝するでしょう。

Rippleは、実際のGoogleの環境(Borgなど)でも一部使われているようなので、今後の機能追加や改善などにも期待したいですね。

参考

Rippleの公式ページ
MySQL Ripple: The First Impression of a MySQL Binlog Server


MySQL

 

Return Top