mysql replicationの設定方法

Contents


mysql レプリケーション 概要

MySQLの最大の特徴はreplication ( レプリケーション )です。読取専用のレプリカを多数作成し、ディスクアクセスが発生しないように大量の読取処理を実現するのが、MySQLの基本的な考え方です。このページでは、replication ( レプリケーション) に関する設定練習ができるよう、一台のOS上でmysqld_multiを用いてreplication ( レプリケーション) 環境を構築する方法を説明します。

mysqld_multiは1つのOS上で複数のmysqld (MySQLサーバ) プロセスを起動させる手法です。具体的な構築方法は、”mysqld_multiの設定方法“を参照下さい。

mysql レプリケーション 環境準備

mysql レプリケーション 環境準備 – 構成説明

mysqld_multiを用いて4つのmysqld ( MySQL サーバ ) プロセスを起動します。4つのmysqld ( MySQL サーバ ) は、以下のようなreplication ( レプリケーション ) 構成を取るように構築します。

mysql_replication_001

このマルチプロセス環境を実現する/etc/my.cnfの設定は以下のようになります。

mysql レプリケーション 環境準備 – ディレクトリ作成

データディレクトリを作成し、初期状態のinnodbを作成します。innodbを作成するには、以下のようにmysql_install_dbというperlスクリプトを利用します。

MySQL用の一時ディレクトリを作成します。

mysql レプリケーション 基本設定

mysql レプリケーション 基本設定 – binary log, relay logの事前説明

MySQLのreplication (レプリケーション)を設定するには、以下4つのキーワードを抑える事が重要です。

  • Binary log ( バイナリログ)
  • Relay log ( リレーログ )
  • I/O thread
  • SQL thread

これら4つのキーワードについて、簡単なMySQL replication (レプリケーション)の動作を図示すると以下のようになります。

mysql_replication_002

MySQL replication ( レプリケーション ) の処理の概要を説明すると次のようになります。

  • Masterサーバに書き込まれた変更処理をBinary logに書き出します。
  • SlaveサーバのI/O threadはBinary logを読み取り、Relay logに変更内容を書き出します。
  • SlaveサーバのSQL threadはRelay logを読み取り、読み取った内容をデータベースに反映させます。

mysql レプリケーション 基本設定 – binary log 設定

MySQLはデフォルトでbinary log (バイナリログ)の出力は無効になっています。従って、replication (レプリケーション)を行なうには、binary log (バイナリログ)の出力を有効にしなければなりません。[mysqld]セクションにlog-binを加筆します。/etc/my.cnfの設定例は以下の通りです。

binary log (バイナリログ) , relay log (リレーログ) のデフォルトのファイル名は、<hostname>-bin, <hostname>-relay-binです。サーバによってファイル名が異なるのは、手順書を書いたり処理を自動化したりする時に不都合です。

replication ( レプリケーション ) を行なう最小限の設定は”log-bin”の一行ですが、ログファイルを固定の名前にし運用しやすいようにしておくと良いでしょう。/etc/my.cnfの設定例は以下の通りです。

動作確認のために、適当なデータベース書き込み処理を発生させます。

binary log ( バイナリログ )が発生した事を確認します。mysql-bin.000001がbinary log (バイナリログ)です。

mysql レプリケーション 基本設定 – server id 設定

MySQL でreplication ( レプリケーション ) を行なうにはサーバ間で異なるserver-idを付与する必要があります。/etc/my.cnfの各[mysqlN]セクションに、server-idの設定を加筆します。

mysqld ( MySQL サーバ ) プロセス毎に異なるserver-idが付与された事を確認します。

mysql レプリケーション 基本設定 – replication ユーザの作成 (Masterサーバの操作)

MySQL Masterとなるサーバにreplication専用のユーザを作成します。rootユーザでも理論上は動作しますが、セキュリティの観点から最小限の権限 REPLICATION, SLAVEのみを与えたユーザを作成するのが一般的です。

mysql レプリケーション 基本設定 – データコピー (Masterサーバの操作)

replication ( レプリケーション ) を開始する時点で、Master / Slave間で同一のデータを保持する必要があります。エキスパートのためのMySQLトラブルシューティングガイドによると、データをコピーする方法は大きく分けて以下の3通りがあります。

  • mysqldumpによるデータコピー
  • /var/lib/mysqlをそのままコピー
  • LVM snapshotを利用したコピー

最も簡単な”mysqldumpによるデータコピー”の方法を紹介します。まずは、どの時点のコピーを取ったかを明確にするため、全てのテーブルに対してREAD LOCKをかけます。

READ LOCKをかけた状態で、MASTER POSTIONをメモに残します。このMASTER POSITIONの値は、binary log (バイナリログ)のどの位置からreplication (レプリケーション )を行なうべきかを指定する際に使用します。MASTER POSITIONを確認するには、”SHOW MASTER STATUS”コマンドを使用します。

MASTER POSITIONの確認が済みましたら、mysqldumpによるコピーを取得します。

READ LOCKを解除します。

mysql レプリケーション 基本設定 – replication 開始 (Slaveサーバの操作)

mysqld2, mysql3に対して、先ほど取得したmysqldumpをSlaveサーバにインポートします。

binary log ( バイナリログ ) のどの位置からreplication (レプリケーション)を行なうべきか指定には、”CHANGE MASTER TO”文を使用します。MASTER_LOG_FILE, MASTER_LOG_POSは先ほどの”SHOW MASTER STATUS”で確認した値を入れて下さい。

replication (レプリケーション)を開始するには、”START SLAVE”コマンドを使用します。

“SHOW SLAVE STATUS”コマンドにより、replication (レプリケーション)が正常に行なわれているかを確認します。Slave_IO_Running, Slave_SQL_RunningがともにYesと表示されている事を確認します。

MySQL Masterにデータを書き込み、その値がMySQL Slaveに反映されている事を確認します。

mysql レプリケーション 孫Slave ( replicatoin chain )

mysql レプリケーション 孫Slave ( replicatoin chain ) – 設定

孫Slave (孫スレーブ) のレプリケーション構成を構築するためには1点だけ注意が必要です。孫Slaveにデータを転送するサーバに対してlog-slave-updatesの1行を加えなければならない事に注意して下さい。

デフォルトの状態ではSQL threadによって書き込まれたレプリケーションによるデータはbinary log (バイナリログ)に書き込まれません。log-slave-updatesを加える事によって、レプリケーションによるデータがbinlog (バイナリログ)に書き込まれるようになります。

/etc/my.cnfの設定例は以下の通りです。

設定反映のため、mysqld ( MySQL サーバ ) の再起動を行ないます。

mysql レプリケーション 孫Slave ( replicatoin chain ) – データコピー (Masterサーバの操作)

データコピーの方法は先ほどの説明の通り、通常のreplication (レプリケーション)の手順と変わりません。説明は省略し、操作コマンドのみ紹介します。

mysql レプリケーション 孫Slave ( replicatoin chain ) – replication 開始 (Slaveサーバの操作)

replication (レプリケーション)の開始方法は先ほどの説明の通り、通常のreplication (レプリケーション)の手順と変わりません。説明は省略し、操作コマンドのみ紹介します。

mysql Semi-Synchronous replication

mysql Semi-Synchronous replication – 概要

mysql Semi-Synchronous replication とは、準同期のレプリケーションです。漢のコンピュータ道の図が一番分かりやすいと思いますので、図をそのまま引用します。

mysql_replication_003

通常、MySQL Masterサーバに障害が発生した際、アプリケーションサーバに正常応答が返ったとしても、binary log (バイナリログ)がSlaveサーバへ転送されている保証はありません。つまり、データロスの可能性があるという事です。

しかし、Semi-Synchronous replicationを使用すると、binary logが転送されるのを待ってから正常応答を返すため、正常応答が返った処理に関してはデータロスがない事を意味します。

mysql Semi-Synchronous replication – プラグインの追加

Semi-Synchronous replicationはMySQL 5.6の標準機能として備わってはいません。使用するためには、追加のプラグインが必要となります。

MySQL Masterとなるサーバに”rpl_semi_sync_master”を追加します。

MySQL Slaveとなるサーバに”rpl_semi_sync_slave ”を追加します。

mysql Semi-Synchronous replication – 設定

mysql1をsemi sync masterとして設定し、mysql2をsemi sync slaveとして設定する例は以下のようになります。追加する設定は以下3行のみで非常にシンプルです。

rpl_semi_sync_master_timeoutはsemi sync modeを解除する閾値で、指定した時間(ミリ秒)以内にbinary log (バイナリログ)を転送できなかった場合は、通常のreplicationに切り替わります。長すぎるとSlaveサーバ高負荷時の応答遅延につながりますし、短すぎるとsemi syncの解除が頻発してしまいます。

設定反映にmysqld (MySQL サーバ) の再起動は必要ございません。以下のようにGLOBAL変数を書き換え、STOP SLAVE / START SLAVEで設定が反映されます。

mysql Semi-Synchronous replication – 動作確認

semi syncを設定すると、semi sync masterとなるサーバ側の”SHOW STATUS”コマンドで、Rpl_semi_syncという変数を確認する事ができます。Rpl_semi_sync_master_clientsが1以上であり、Rpl_semi_sync_master_statusがONになっている事を確認します。

semi sync slaveが障害または高負荷時は、Rpl_semi_sync_master_statusがOFFと表示されます。

mysql replication Multi-Threaded Mode

mysql replication Multi-Threaded Mode 概要

MySQL 5.6の新機能で、マルチスレッド レプリケーションがあります。これはデータベース単位で複数のSQL Thread Threadが起動するモードです。なお、ひとつのデータベースに対してはシングルスレッドで動作しますので、データベースがひとつしか存在しない環境においては、マルチスレッド化の恩恵を受ける事はできません。

マルチスレッドの構成を図で表すと以下の通りです。

mysql_replication_004

mysql replication Multi-Threaded Mode 設定

マルチスレッド レプリケーションの設定は非常に簡単です。最小限の設定は、slave_parallel_workersの1行のみです。

マルチスレッド化の設定は、mysqld (MySQL サーバ) の再起動は必要ございません。以下のようにGLOBAL変数を書き換え、STOP SLAVE / START SLAVEで設定が反映されます。

mysql replication Multi-Threaded Mode 動作確認

マルチスレッド レプリケーションはデータベース単位でSQL threadが動作します。従って、動作確認を行うには複数データベースに対して書き込みを行なう必要があります。

複数スレッドのSQL threadを管理するファイルが作成されている事が確認できます。

“relay-log-info-repository=TABLE”としている場合は、SQL threadに関する情報はテーブルに書き出されます。確認方法は以下の通りです。

Tips

–master-data

MySQL Masterサーバのコピーを作成するにあたり、ロック操作、MASTER POSITIONの記録など非常に煩雑な作業が多数存在します。このような手間は、mysqldumpに–master-dataオプションを渡す事によって解消する事ができます。

使用例は以下の通りです。master-dataに1を渡すとCHANGE MATERがmysqldump内に生成されますので、手作業でCHANGE MASTER文を投入する必要はございません。master-dataに2を渡すとCHANGE MASTER文がコメントアウトされた状態でmysqldumpが生成されます。replication ( レプリケーション ) を開始前に目視確認を行いたい場合は、master-dataに2を渡すと良いでしょう。

AWS RDSにおけるレプリケーション

AWS (Amazon Web Services) は、RDSと呼ばれるRDBMSの仕組みが存在します。現時点(2014/08/17)でRDSでMySQLレプリケーションを実装する場合の方法について説明します。

AWSは頻繁に使用が変わるので、この手順が有効であるのは1年も持たないかもしれません。手順を眺めて、AWSの便利さと制約の多さを感じ取って頂けると幸いです。

AWS RDS レプリケーション設定

オンプレミス環境では、MySQLレプリケーションを行なうにあたり、bin log, server-idなどMySQLパラメタに注意を払わなければなりません。AWS RDSでは自動的にbin logとserver-idが設定されます。

唯一の注意点と言えば、Backupを有効にする事です。Backup Retention Periodを”0 day”と設定すると、binlog自体の出力が無効化されてしまうので、レプリケーションが行なえなくなります。

mysql_replication_005

RDS to RDS レプリケーション

RDS間でレプリケーションを行なうのは非常に簡単です。”Create Read Replica”を押下するだけで、レプリケーション用ユーザの作成, データベースコピー, CHANGE MASTER文発行などの操作を自動的に行なってくれます。

mysql_replication_006

MySQLマスター側のプロセスを観察すると、”rdsrepladmin”というユーザが作成されレプリケーションが行なわれている事が観察できます。

MySQL Slave側では、オンプレミス環境と同様に、”show slave status”による確認が可能です。

RDS to EC2 レプリケーション

RDSからEC2へ、またはRDSからオンプレミスへのレプリケーションを行なう手順を説明します。現時点(2014/08/17)の仕様では、軽く20, 30分触っただけで以下のような運用上の困難が多数見つかってしまいました。

  • “FLUSH TABLES”権限がないため、mysqldump取得時のMASTER POSITIONの位置が不明確。
  • RDSが自動生成するCNAMEが64bitを超える可能性があり、レプリケーションの宛先ホストとして設定できない可能性がある。
  • RDSのMySQLデータベースにはRDS固有情報が格納されており、取り扱いに注意が必要である。
RDS to EC2 レプリケーション – マスター側の操作

レプリケーション用ユーザの作成操作は、オンプレミス環境と全く変わらない手順です。

データコピーに関しては一癖あります。AWS RDSではroot権限を持ったユーザが与えられないため操作が限られています。“FLUSH TABLES WITH READ LOCK”を実行する権限がないため、mysqldumpを取得した時点のMASTER POSITIONを把握する事ができません。

mysqldumpを取得する際に一切のアクセスを禁じるようなセキュリティグループを作成する、目視でバイナリログファイルを読み取りMASTER POSITIONを推測する等の何らかの工夫が必要となります。

また、mysqldumpでインポート/エクスポートする対象のデータベースには注意を払ってください。mysqlデータベースはRDS固有の管理情報が格納されていますので、コピー対象に含めない方が良いでしょう。

RDS to EC2 レプリケーション – スレーブ側の操作

mysqldumpはインポートは、通常の手順と全く変わりません。

mysqlなど一部データベースはレプリケーション対象に含めると不都合が生じてしまいますので、レプリケーション対象から除外します。replicate-ignore-dbを/etc/my.cnfに設定します。

CHANGE MASTER文を発行する際は、MASTER_HOSTにCNAMEを指定できない事があります。なぜなら、ホスト名指定が64bitまでと決められているので、CNAMEを使用する場合は64bitの上限に抵触する可能性があります。

ですので、64bit未満のホスト名かIPアドレスで指定せざるを得ません。CHANGE MASTER 文の実行例は以下の通りです。

レプリケーションが正常に行なわれている事を確認します。Slave_IO_Running, Slave_SQL_Runningが共にYESと表示されている事を確認します。

EC2 to RDS レプリケーション

EC2からRDSへ、またはオンプレミスからRDSへのレプリケーションを行なう手順を説明します。

EC2 to RDS レプリケーション – マスター側の操作

MySQL マスターとなるEC2またはオンプレミス環境の操作は、通常のオンプレミスの手順と変わりありません。具体的な操作手順は省略します。

EC2 to RDS レプリケーション – スレーブ側の操作

RDSは”CHANGE MASTER TO”等のレプリケーションに関する操作権限は与えられていませんが、その代わりにAmazonが予め用意したストアドプロシジャーを利用してreplication(レプリケーション)を設定します。

まずはどのようなストアドプロシジャーが存在するのかを観察してみましょう。

ストアドプロシジャーの具体的な実装は、”SHOW CREATE PROCEDURE”により確認する事ができます。

さて、具体的な操作手順に話を戻しましょう。RDSでは、”CHANGE MASTER TO”文の変わりに、”rds_set_external_master”というストアドプロシジャーを使います。使用方法は、CHANGE MASTER TOと殆ど同じです。

“START SLAVE”に相当するのは、”rds_start_replication”です。

確認コマンドは通常通りの”SHOW SLAVE STATUS”を使用する事ができます。Slave_IO_Running, Slave_SQL_Runningが共にYESになっている事を確認します。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする