前回記事:MySQLにおける4つのログファイルの設定と確認方法では、MySQLから出力される4種類のログの出力設定方法と内容の読み方についてご紹介しました。
今回はMySQLで使用できるレプリケーション機能の設定方法ついて、詳しくご紹介したいと思います。
目次
1.1 レプリケーションとは
1.2 レプリケーションの仕組み
1.3 レプリケーションのメリット
1.4 レプリケーションのデメリット
3.1 専用ユーザを作成する
3.2 マスターの設定を行う
3.3 スレーブの設定を行う
3.4 バイナリログの情報を確認する
3.5 バックアップデータを取得する
3.6 バックアップデータを展開する
3.7 マスターの情報を登録する
3.8 レプリケーションをスタートする
1.レプリケーションとは?
1.1 レプリケーションとは
レプリケーション機能とは、データのレプリカ(複製)を作成して別の場所にバックアップしておく、つまりデータベースをミラーリングする機能のことです。
1.2 レプリケーションの仕組み
MySQLのレプリケーション機能では、まず「マスター」と呼ばれるメインのデータベースサーバに対して、1つまたは複数の「スレーブ」と呼ばれるデータベースサーバを用意します。マスターは複数のスレーブを持つことが可能ですが、スレーブが持てるマスターは1つです。
まずスレーブから、マスターへレプリケーションの開始をリクエストします。
マスターはリクエストを受け取ったら、更新内容を記録したデータをスレーブに転送します。
スレーブは更新内容を受け取ったら、自分のデータベースに反映します。
MySQLはこれらの転送処理をリアルタイムに行わなくてもいい「非同期」に対応しているため、マスターとスレーブは常に接続しておかなくてもよいという特徴があります。
1.3 レプリケーションのメリット
MySQLのレプリケーションのメリットには、主に次の3つが挙げられます。
■負荷分散ができる
データベースの更新はマスターサーバで行う必要がありますが、参照はスレーブサーバでも行うことが可能です。そのため参照が多いシステムにおいては、参照用にスレーブサーバを使用することで、マスターサーバの負荷を軽減することができます。
■サーバを停止させずにコールドバックアップが取得できる
マスターを稼働させたままスレーブのデータから、コールドバックアップを取得することが可能です。そのため、マスターをパフォーマンスの低下や破損などのダメージから守ることができます。
■サーバ障害に強くなる
マスターで障害が発生した際にはスレーブをマスターに置き換えて使用することで、システムの可用性を高めることができます。
1.4 レプリケーションのデメリット
対するデメリットとしては、次のようなものが考えられます。
■必要なリソースが増える
スレーブはマスターの完全なバックアップを保存しているため、マスターと全く同じだけの容量がスレーブの数だけ必要になるという問題があります。
■問題点までコピーされてしまう
更新を完全に「同期」していた場合、例えば誤操作を行ったため必要なデータを削除してしまったという場合も瞬時に同期が取られてしまうため、誤操作も含まれた状態でミラーリングされてしまうというデメリットもあります。
(ただ「非同期」および「準同期」がメインのMySQLでは、この問題は発生し難いかと思います)
2.同期方式の種類
レプリケーションを行う場合、その同期方式には大きく分けて3種類あります。
2.1 同期
マスターとスレーブを常に接続し、リアルタイムに変更点をスレーブに反映します。
マスターに障害が発生した場合もごく直前の更新内容までスレーブに保存されているというメリットがありますが、問題の内容までリアルタイムに転送してしまう恐れがあります。
2.3 準同期
マスターからスレーブへの変更点の転送のみリアルタイムで行い、スレーブ側データベースへの変更点の反映については非同期で行います。
障害発生直前のデータも転送は行われていつつ、問題までリアルタイムに転送されてしまわないというメリットがあります。
MySQLは、デフォルトでは「非同期」に対応しています。さらにMySQL Server 5.5からは、プラグインを導入することで「準同期」にも対応できるようになっています。
3.レプリケーション機能の設定方法
3.1 専用ユーザを作成する
まず、レプリケーションを行うための専用のユーザを作成します。
rootユーザ等でも設定は可能ですが、レプリケーション関連に限定した権限を持たせた専用ユーザを使用する方がセキュリティの関係からもおすすめです。
3.2 マスターの設定を行う
マスター側では、まずバイナリログの出力を有効にします。(デフォルトでは無効です)
バイナリログの出力設置について詳しくは、次の記事をご参照下さい。
次に、マスターサーバの「サーバID」を設定します。
設定ファイル(Windowsの場合:my.ini/UNIX系の場合:my.cnf)の[mysqld]配下に、次の記述を追加します。
server-id=[任意の数字]
IDには「1~4294967295」のうち任意の数字を使用可能ですが、1や2などは未設定の場合にデフォルトで使用される数字なので、避けた方が無難です。
3.3 スレーブの設定を行う
今度は、スレーブ側サーバの「サーバID」を設定します。
マスターと同じく設定ファイルの[mysqld]配下に、次の記述を追加します。
server-id=[任意の数字]
こちらも「1~4294967295」のうち任意の数字を使用可能ですが、同じく1や2、そしてマスターや他のスレーブと同じ数字は避けるようにします。
なおマスター、スレーブ共に、設定ファイルを書き換えたらサービスを再起動して設定を反映しておいて下さい。
3.4 バイナリログの情報を確認する
まず、マスター側でバイナリログのファイル名と現在のポジションを確認しておきます。
確認するためのコマンドは、次の通りです。
SHOW MASTER STATUS;
実行結果に、「File」と「Position」という項目があります。
・File・・・バイナリログのファイル名
・Position・・・現在のポジション
この2項目を記録しておきます。
3.5 バックアップデータを取得する
マスター側データベースのバックアップを、mysqldumpを用いて取得します。
その際、必要に応じてテーブルをロックします。
mysqldumpの使用方法について、詳しくは以下の記事をご覧下さい。
3.6 バックアップデータを展開する
スレーブ側サーバに、上記で作成したdumpファイルを展開します。
dumpファイルの展開方法について詳しくは、下の記事をご覧下さい。
3.7 マスターの情報を登録する
スレーブ側サーバに、マスター側サーバの情報を登録します。
CHANGE MASTER TO
MASTER_HOST = '[マスターのIPアドレス]',
MASTER_USER = '[最初に作成した専用ユーザ]',
MASTER_PASSWORD = '[専用ユーザのパスワード]',
MASTER_PORT = [マスターのポート番号],
MASTER_LOG_FILE = '[バイナリログのファイル名]',
MASTER_LOG_POS = [バイナリログのポジション];
3.8 レプリケーションをスタートする
スレーブ側サーバで、スタートするコマンドを実行します。
START SLAVE;
これで基本的な非同期レプリケーションの設定は完了です。
さらに準同期にしたい場合は、まずこの非同期版の設定を行った上で、準同期レプリケーション用プラグインを導入することで対応します。
4.まとめ
次回はMySQLでよくあるエラーとその対処法について、詳しくご紹介したいと思います。
よければ合わせてご覧下さい。