mysql57_20151025_0002

2015/10/21に、MySQL5.7(5.7.9) Major Versionが正式リリースされましたね。貧乏な私はMySQL 5.6の3倍の性能と言われましてもプアーなマシンでしか動かせないのでじっと指を咥えて他人様のベンチ結果を見守ることにします。 (´・_・`)

さて、MySQL 5.7の目玉機能といえば、マルチソースレプリケーションではないでしょうか。これが実現できることで何が嬉しいかといいますと、例えばバラバラと構築したマスターがn台あったとしてnx2台のスレーブ作る必要がなく、1〜2台の大きなスレーブに集約できたりするわけです。(んで、behindがなくなったらこいつを新マスターにしてしまえる!) というわけで、さくらのクラウドでCentOS7のサーバーを構築し、マルチソースレプリケーションを試してみました。ネットワーク構成は以下になります。

mysql57_20151025_0001

master0192.168.0.230
master1192.168.0.231
slave0192.168.0.232
slave1192.168.0.233

 

プライベートIPアドレスはeth1に振っています。さくらのクラウドでCentOS7のeth1にIPアドレスを振る手順はこちらを参考にどうぞ。

今回構築するサーバーの、マスターとスレーブの関係は以下の通りです。

  • master0 は test0 データベースのマスター。チャネルは0
  • master1 は test1 データベースのマスター。チャネルは1
  • slave0 は 上記すべてのデータベースのスレーブになる
  • slave1 は 上記すべてのデータベースのスレーブになる

mysql57_20151025_0002

ちなみに、マルチソースレプリケーションはマルチマスターレプリケーションとイコールではありません。 こちらの図表を見ると違いが一目瞭然ですが、マルチマスターレプリケーションは循環型のレプリケーションで、SQLクライアントはどのノードに書き込みを行っても、レプリケーションを構成するすべてのノードに等しくデータが同期されます。いっぽう、マルチソースレプリケーションは上記のDB構成図のように、1つのスレーブが複数のマスターを持つことができる仕組みです。

■ MySQLサーバーを「ほぼ」一撃構築する

Master Slaveともに共通の設定をこちらの一撃シェルスクリプトをもとに作成します。スクリプトの文字数が10000文字を超えてしまったのでスタートアップスクリプトに登録できなかった。残念!

最初に変数「INTERFACE」「IPOCT4」を指定していますが、前者はipコマンドでループバックインターフェイス以外の一覧から先頭のデバイスを検出し、IPv4アドレスの最後のオクテットの数字を抜き出しています。これを「NEWHOSTNAME」変数でホスト名にしたり「SERVERID」変数でMySQLのサーバーIDに代入したりしています。ネットワークが/24までならホスト名やサーバーIDが被ることはないですが、それ以上のネットワークの場合はよしなに編集していただきたく。。。

一応ここまでが今回の4台に共通の設定なので、一撃構築となりますが、ここから先は個別のカスタマイズです。なのでフルオートメーションじゃありません>< あと、今回の一撃シェルスクリプトはCentOS6とCentOS7で動作確認をしています。以下の作業はMasterとSlaveでそれぞれ別の作業をするので、どちらのサーバーで作業するかを見出しに書いておきますね。

■ [Master]my.cnf編集

/etc/my.cnf の [mysqld] セクションに binlog-ignore-db=mysql を追記してバイナリログにmysqlデータベースの変更を記録しないようにします。

以下追記

保存したらmysqldを再起動します。

■ [Master]レプリケーション用ユーザーを作成する

以下のID、パスワードでレプリケーション用ユーザーを作成します。すべてのDB、テーブルに対してREPLICATION SLAVEの権限を与えます。

IDmsandbox
パスワードmsandbox

■ [Slave]my.cnf編集

MySQLでマルチソースレプリケーションを行うためには、スレーブをクラッシュセーフにする必要があります。このため、 [mysqld] セクションに以下を追記します。

もう1つ、 replicate-ignore-db パラメータに mysql を指定しないと、MySQLのID、パスワードまでマスターから同期されてしまいます。なので、以下の1行も追記します。

上記3行を追記して保存したらmysqldを再起動します。

■ [Master]バイナリログのポジションを確認する

master0サーバーとmaster1サーバーで、SHOW MASTER STATUSを実行します。

■ [Slave]チャネルを指定してスレーブのプロセスを作成する

CHANGE MASTERコマンドでマスターサーバーのスレーブになります。以下のコマンドを見ると、普通のMaster/Slave構成のレプリケーションと同じようですが、引数「FOR CHANNEL」をつけて、どのチャネルのスレーブになるかを指定する必要があります。また、チャネル名はダブルクォートで囲ってあげましょう。

mysqlクライアントからは以下のように実行します。

bash等のシェルからは以下のように実行します。

それでは START SLAVEします。mysqlクライアントからは以下のように実行します。

bash等のシェルからは以下のように実行します。

CHANGE MASTERコマンドでマスターのバイナリログ名とポジションを引数に与えず実行してしまうと、SHOW SLAVE STATUSで以下のエラーが出てしまうことがあります。

そんな時は慌てず騒がず STOP SLAVEとRESET SLAVEしてスレーブのmysqldを再起動しましょう。なお、slave側の /etc/my.cnf で replicate-ignore-db=mysql の記述を忘れると、この時点でMySQLのrootパスワードがマスターから転送されて変更されてしまうので注意しましょう。

■ [Slave]ステータス確認

それではスレーブのステータスを確認してみましょう。Masterが1台、Slaveが1 or n台のときは「show slave status\G」でスレーブのステータスが確認できますが、今回のようにマルチソースレプリケーションだと、チャネル名を指定しないと何も出力されません。mysqlクライアントからは以下のように実行します。

bash等のシェルからは以下のように実行します。

実際の出力例はこんな感じです。(クリックで大きくなります)

チャネルを指定することで、スレーブのステータスを確認することができました。また、チャネルごとに Master_Host Master_UUID Channel_Name が異なっていることがわかります。(もちろんMaster->Slaveの転送状況も)

■ [Master]データベースを作成する

master0サーバーでtest0データベースを作成します。

次にmaster1サーバーでtest1データベースを作成します。

■ [Slave]データベース一覧を確認する

スレーブにこれらDBが転送されてきているかを確認します。

マスターサーバーにはtest0かtest1のどちらかのデータベースしかありませんでしたが、スレーブの2台には両方のデータベースができています。データがごちゃごちゃにならないよう、まだまだ細かい設計が必要ですが、これで最低限のマルチソースレプリケーション設定はおしまいです。ね、簡単でしょう?

関連記事

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です