今回新しく MySQL 関係のコラムを担当することになりました、潮です。
主に MySQL と Oracle Database の構築、技術サポートを担当しています。
以後よろしくお願いいたします。
さて、2015年10月にオラクル社より MySQL 5.7のGA版がリリースされました。
5.7.9が GA の最初のバージョンで、原稿執筆時点（2016/1/28）では5.7.10が最新版となっています。
MySQL 5.6から5.7にバージョンアップされることに伴い、いくつか機能追加や性能改善が行われました。
それらをご紹介したいと思います。
本記事では、【マルチソースレプリケーション】を扱います。
マルチソースレプリケーションとは？
MySQL 5.7 で新規追加された、複数のマスターのデータを1つのスレーブに集約する機能です。
従来からできた、マスター：スレーブが1：Nのレプリケーションに加え、N：1のレプリケーションができるようになりました。
マルチソースレプリケーションの仕組み
仕組みはこちらの図の通りです。
5.7 では、5.6 以前でもあった Slave I/O Thread と Slave SQL Thread を束ねる、「Channel」という概念が作られました。（厳密には、MySQL Cluster Replication で Channel という言葉は使われていましたが。）
1つの Channel が1つのマスター情報を持つ仕組みになっており、Channel はスレーブ1台に対して複数持つことができるようになっているため、これにより複数のマスターからの更新を受け付けることができるようになりました。
設定方法は？
5.6以前と変わらず、スレーブで change master to ～の構文を使ってマスターの情報を入力します。
異なるのは、change master to ～構文の最後に for channel ‘任意のチャネル名’ が入る点です。
change master to ～ はチャネル名を変えて、全てのマスターに対して実行します。
なお、マスターでは特段設定は不要です。
# マスターの情報を入力します。
mysql> change master to master_host='172.30.50.64',
-> master_user='repl',
-> master_password='XXXXXXXX',
-> master_auto_position=1
-> for channel 'repchannel1'; #★追加設定
Query OK, 0 rows affected, 2 warnings (1.73 sec)
# レプリケーションを開始します。
mysql> start slave for channel 'repchannel1';
Query OK, 0 rows affected (0.08 sec)
確認例
設定の確認は、スレーブで show slave status for channel ‘チャネル名’ コマンドを実行することで可能です。
mysql> show slave status for channel 'repchannel1'G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.30.50.64 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-fabric2-bin.000001 Read_Master_Log_Pos: 160771 Relay_Log_File: mysql-fabric1-relay-bin-repchannel1.000002 Relay_Log_Pos: 438 Relay_Master_Log_File: mysql-fabric2-bin.000001 Slave_IO_Running: Yes #★レプリケーションの確認ポイント Slave_SQL_Running: Yes #★レプリケーションの確認ポイント ～～～（中略）～～～ Channel_Name: repchannel1 #★指定したチャネル名
5.6以前と同様、
Slave_IO_Running: Yes かつ Slave_SQL_Running: Yes
であればレプリケーションが行われていることが確認できます。
どのChannelの設定であるかは、出力の最後の
Channel_Name:
という項目から、可能です。
どんな時に使えるか？
複数拠点で別々に管理しているMySQLサーバのデータを単一拠点で集中管理する運用に変更する際のデータ集約や、各拠点で蓄積したデータを統合してBI分析を始めたい、などの場合に利用できます。
新たに注意しなくてはならなくなる点は？
マスターに頻繁に更新がかかる場合、スレーブサーバの書き込み性能が問題になり得ます。
今まではスレーブサーバにはマスターと同等の書き込み性能があれば十分でしたが、複数のマスターを持つ場合、マスターを超える書き込み性能が必要となる可能性があります。
また、マスター同士での情報の連携はしていませんので、この点も注意が必要です。
是非この記事をお読み頂いた方も試してみて下さい。