Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  レプリケーション

第 17 章 レプリケーション

目次

17.1 レプリケーション構成     [+/-]
17.2 レプリケーションの実装     [+/-]
17.3 レプリケーションソリューション     [+/-]
17.4 レプリケーションの注釈とヒント     [+/-]

レプリケーションによって、1 つの MySQL データベースサーバー (マスター) のデータを、1 つまたは複数の MySQL データベースサーバー (スレーブ) に複製できます。レプリケーションはデフォルトで非同期であるため、スレーブはマスターから更新を受け取るために永続的に接続されている必要はありません。これは、長距離間接続でも、さらにダイアルアップサービスのような一時的または断続的接続上でも更新が可能であることを意味しています。構成に応じて、すべてのデータベース、選択したデータベース、さらにデータベース内の選択したテーブルを複製できます。

MySQL Replication をはじめて使用する人がよくする質問の回答については、セクションA.13「MySQL 5.6 FAQ: レプリケーション」を参照してください。

MySQL のレプリケーションの長所は次のとおりです。

  • スケールアウトソリューション - パフォーマンスの向上のために複数のスレーブに負荷を分散します。この環境では、すべての書き込みと更新をマスターサーバーで実行する必要があります。ただし、読み取りの場合は、1 つ以上のスレーブで実行してもかまいません。このモデルでは、書き込みのパフォーマンスを向上させながら (マスターが更新専用であるため)、スレーブ数が増加しても読み取り速度を劇的に速めることができます。

  • データセキュリティー - データはスレーブに複製され、スレーブはレプリケーションプロセスを一時停止できるため、対応するマスターデータを壊すことなくスレーブでバックアップサービスを実行できます。

  • 分析 - マスターでライブデータを作成しながら、スレーブで情報の分析を実行できるため、マスターのパフォーマンスに影響しません。

  • 長距離データ配布 - 支店でメインデータのコピーを使用して作業する場合に、レプリケーションを使用してデータのローカルコピーを作成してそれらを使用できます (マスターへの永続的なアクセスは不要)。

MySQL のレプリケーションの特徴は、一方向の非同期レプリケーションをサポートしていることであり、1 つのサーバーがマスターとして機能し、1 つまたは複数のサーバーがスレーブとして機能します。これは、MySQL クラスタの特徴である同期レプリケーションとは対照的です (第18章「MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4を参照してください)。MySQL 5.6 では、組み込みの非同期レプリケーションに加えて、準同期レプリケーションへのインタフェースがサポートされています。準同期レプリケーションでは、マスター側で実行されたコミットは、トランザクションを実行したセッションに戻る前に、少なくとも 1 つのスレーブがトランザクションのイベントを受け取ってログに記録したことを通知するまでブロックされます。セクション17.3.8「準同期レプリケーション」を参照してください。MySQL 5.6 は、スレーブサーバーが、少なくとも指定した時間だけ意図的にマスターより遅れるような遅延レプリケーションもサポートしています。セクション17.3.9「遅延レプリケーション」を参照してください。

2 つのサーバー間でレプリケーションをセットアップするために使用できるソリューションはいくつかありますが、最善の使用方法はデータの存在や使用しているエンジンタイプによって異なります。利用可能なオプションの詳細については、セクション17.1.1「レプリケーションのセットアップ方法」を参照してください。

レプリケーション形式の主要なタイプは 2 つあり、1 つは、SQL ステートメント全体を複製する Statement Based Replication (SBR: ステートメントベースレプリケーション)、もう 1 つは変更があった行だけを複製する Row Based Replication (RBR: 行ベースレプリケーション) です。3 つ目の Mixed Based Replication (MBR: ミックスベースレプリケーション) を使用することもできます。さまざまなレプリケーション形式の詳細については、セクション17.1.2「レプリケーション形式」を参照してください。MySQL 5.6 では、ステートメントベースの形式がデフォルトです。

MySQL 5.6.5 以降では、グローバルトランザクション ID (GTID) に基づくトランザクションレプリケーションをサポートしています。このタイプのレプリケーションを使用するときは、ログファイルまたはこれらのファイル内の位置と直接連携する必要がないため、共通する多くのレプリケーションタスクが大幅に単純化されます。GTID を使用するレプリケーションは完全にトランザクション対応であるため、マスターで確定されたすべてのトランザクションがスレーブでも適用されるかぎり、マスターとスレーブとの一貫性は保証されます。GTID および GTID ベースのレプリケーションの詳細については、セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。

レプリケーションは、いくつかのオプションと変数によって制御されます。これらは、レプリケーション、タイムアウト、データベース、およびデータベースとテーブルに適用できるフィルターのコア操作を制御します。利用可能なオプションの詳細については、セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。

レプリケーションを使用することで、いくつかの異なる問題を解決できます (パフォーマンスの問題、異なるデータベースのバックアップのサポート、より大きなソリューションの一部としてシステム障害を軽減する、など)。これらの問題の対処方法については、セクション17.3「レプリケーションソリューション」を参照してください。

レプリケーション機能の詳細、バージョン互換性、アップグレード、および問題とその解決 (FAQ を含む) など、さまざまなデータ型とステートメントがレプリケーション中にどのように処理されるかに関する説明とヒントについては、セクション17.4「レプリケーションの注釈とヒント」を参照してください。

レプリケーションの実装、レプリケーションの仕組み、バイナリログのプロセスと内容、バックアップスレッド、およびステートメントの記録とレプリケーションの方法を決めるために使用されるルールの詳細については、セクション17.2「レプリケーションの実装」を参照してください。


User Comments
  Posted by on December 18, 2002
Handy mysql log rotation script. For those not
using any chroot environements, comment out both
lines in #chroot section. Set MYSQL_HOME QUERYLOG
SLOWLOG ERRLOG appropiately.

#!/bin/sh
###############################################
# MySQL log rotation
# mjaw@ipartners.pl
###############################################

# chroot
VIRTUAL="/virtual"
VIRTUAL_HOME="${VIRTUAL}/mysql"

# mysql
MYSQL_HOME="${VIRTUAL_HOME}/usr/local/mysql"
DATADIR="${MYSQL_HOME}/var"
LOGDIR="${MYSQL_HOME}/log"
QUERYLOG="${LOGDIR}/querylog"
SLOWLOG="${LOGDIR}/slowlog"
ERRLOG="${LOGDIR}/errlog"

# most universal method for calculating
yesterday's date in YYYYMMDD format
DATE=`/usr/bin/perl -e
"@a=localtime(time-86400);printf('%02d%02d%02d',@a[5]+1900,@a[4]+1,@a[3])"`

PID_FILE=$DATADIR/`/bin/hostname`.pid

if ! [ -s ${PID_FILE} ]; then
echo " Error: pid file not found."
exit 1;
fi

PID=`cat $PID_FILE`

echo -n "Rotating logs: "

if [ -e ${QUERYLOG} ]; then
echo -n "querylog "
/bin/mv ${QUERYLOG} ${QUERYLOG}.${DATE}
fi
if [ -e ${SLOWLOG} ]; then
echo -n "slowlog "
/bin/mv ${SLOWLOG} ${SLOWLOG}.${DATE}
fi
if [ -e ${ERRLOG} ]; then
echo -n "errlog "
/bin/mv ${ERRLOG} ${ERRLOG}.${DATE}
fi

/bin/kill -1 $PID
</PRE>
Run from cron at midnight.
  Posted by S Harper on June 19, 2008
To answer the above question, in the current version, replication supports parallel processing for reads, but you have to be extremely careful for writes.

There is, however, a way around the write limitations in most application situations.

Let's say you have two websites: Each site _could_ be (and in many default situations is) hosted on its own server with its own cpu and MySQL database.

The problems inherent in that situation are reliability (uptime), waste of system resources and lack of flexibility with system resources.

So instead you setup both websites to run on both servers. (Details of IP level load balancing are beyond the scope of this post, but there are lots of options available.) Now, if you've limited your application appropriately, you could setup both servers to write to each other, but I personally wouldn't recommend that you accept that limitation, as it can be fraught with hidden dangers.

Besides, in most applications, the vast majority of the load is reads, not writes.

The language your application is written in is probably implemented with pools of database connectors to service application threads. Using that model, you would setup a pool of read threads on each server to balance their reads from their local MySQL database and the replicated one on the other server.

For writes, you would setup your connectors on both servers to use the master MySQL database for writes, then setup a different pool of connectors for writes to use the slave database. You'll have to handle the error at your application level, but when the master is unavailable, then you switch your application to start writing to the slave instead.

You'll need to write some explicit error handling to tell the slave it's now the master and prevent the original master from being used for reads or writes until it has become the slave in turn and refreshed itself from the slave.

Writing a record to the database immediately after a transition from slave to master to use as a locking mechanism can help ensure that your application always knows what state the two (or more) MySQL databases are in with regards to which pool of connectors writes should be sent to.

A cleaner solution, but much more expensive option in terms of hardware, would be to use two database servers with a hardware IP level load balancer between them and the application servers. In that case, use the same method of using different connection pools for reads and writes, but configure them to hit one IP for each, then configure the load balancer to send the read IP address to both database servers, while only sending the write IP address to one database server at a time. The other database server(s) would be configured to only have traffic sent to them for the write IP address if the original has failed.

You could then safely chain multiple databases to each other for circular writing, but still ensure that all writes only originate in the correct sequence because unless there is a database failure, they are only performed on one database server.

Of course, before you try any replication scheme, be sure to read http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html and the rest of this section of the manual looking for gotchas!
  Posted by Achilleterzo on May 7, 2005
Im testing replication structured master to cascade of slave servers but i got sync problem if a client use a slave to insert/update data.
Waiting for a master-2-master replication i solved this issue by a little cron in php:

$db = mysql_connect("master-host","master-user","master-pwd") or $db = false;
if ($db!=false) {
mysql_close($db);
$db = mysql_connect("localhost","local-user","local-pwd") or die ("Could not connect to MySQL");
mysql_select_db("my_database",$db);
mysql_query("stop slave; DROP DATABASE my_database; load data from master; start slave;");
mysql_close($db);
}
  Posted by Jerome Davies on May 19, 2005
If you are using InnoDB tables, remember that nothing is replicated until the transaction is completed, so if you need to read information to complete the transaction that is dependent upon what has been written eg the value of an auto_increment field, you need to read it from the master.
  Posted by Nick Doyle on April 10, 2012
For anyone looking to add databases (not just slaves) to running replication, I wrote the following script which works pretty well:
http://rdkls.blogspot.com.au/2011/04/adding-new-database-to-running-mysql.html

It's useful in a number of scenarios, but for me mainly if
1. Your server has many DBs, and you want to bring slave DBs online one-by-one while having replication continue to run
2. One database on the slave gets out of sync with the master and it is faster to recreate from backups
  Posted by Lasantha Aberathna on September 13, 2012
If you are looking for step by step explanation about replication setup. Please follow http://lasanthals.blogspot.com/2012/09/mysql-replication-server-configuration.html
Sign Up Login You must be logged in to post a comment.