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


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

17.2 レプリケーションの実装

レプリケーションは、データベースへのあらゆる変更 (更新、削除など) をバイナリログで追跡するマスターサーバーに基づきます。バイナリログは、サーバーが起動した瞬間からデータベースの構造または内容 (データ) を変更するあらゆるイベントが書き込まれた記録として機能します。SELECT ステートメントは通常、データベースの構造および内容を変更しないため記録されません。

マスターに接続する各スレーブはバイナリログのコピーを要求します。つまり、マスターがスレーブにデータをプッシュのではなく、スレーブがマスターからデータをプルします。スレーブはまた、それが受け取るバイナリログからイベントを実行します。これによって、元の変更がマスターで実行されたように繰り返されることになります。マスターで最初に実行された変更に応じて、テーブルが作成されたり、それらの構造が変更されたり、データが挿入、削除、更新されたりします。

各スレーブは独立しているので、マスターのバイナリログからの変更の再生が、マスターに接続された各スレーブで単独に発生します。さらに、各スレーブはバイナリログのコピーをマスターから要求することでのみ受け取るため、スレーブはそれ自身のペースでデータベースのコピーを読み取ったり更新したりでき、マスター側またはスレーブ側で最新のデータベースステータスを更新できる能力に影響を与えずにレプリケーションプロセスを自由に開始したり停止したりできます。

レプリケーション実装の仕様に関する詳細は、セクション17.2.1「レプリケーション実装の詳細」を参照してください。

マスターとスレーブは、レプリケーションプロセスに関するステータスをモニターできるように、定期的にそれらを報告します。すべてのレプリケーション関連ステータスの説明については、セクション8.12.5「スレッド情報の検査」を参照してください。

マスターバイナリログは、スレーブ上のローカルリレーログに書き込まれてから処理されます。スレーブは、マスターのバイナリログとローカルリレーログと一緒に、現在の位置に関する情報も記録します。セクション17.2.2「レプリケーションリレーおよびステータスログ」を参照してください。

データベース変更は、さまざまな構成オプションおよびイベント評価を制御する変数に従って適用されるルールセットに応じて、スレーブ上でフィルタされます。これらのルールがどのように適用されるかについての詳細は、セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。


User Comments
  Posted by David Tonhofer on September 10, 2004
When setting up replication from one database to another on the same machine I *strongly* recommend compiling MySQL once as the master server and once as the slave server, both with their separate 'localstatedir' and 'port' given in the "configure" command. Then give each its own my.cnf in its respective 'localstatedir'. Finally, make sure either the master's 'bin' is in your PATH if your want to work with master or the slave's 'bin' is in your path if you want to connect to the slave. Otherwise you *will* make an error sooner or later regarding to which server you are connected.

And passing --port on the command line does not help: unexpectedly, it does NOT override the value found in my.cnf.

Good luck!

  Posted by no no on January 15, 2005
"After the slave has been set up with a copy of the master's data, it will simply connect to the master and wait for updates to process. If the master goes away or the slave loses connectivity with your master, it will keep trying to connect periodically until it is able to reconnect and resume listening for updates. The retry interval is controlled by the --master-connect-retry option. The default is 60 seconds."

Note the above is not the case in MySQL 4.0.22 -- documentation might need to be updated to clarify which version it is talking about. (FWIW, just had a master die, come back up, and 10 minutes later the slaves still thought they were connected to the first instance.)
  Posted by Joao S. O. Bueno Calligaris on October 22, 2005
For tables other than MyISAM, a work around is to create the table structure on the slave server with ENGINE=FEDERATED, pointing at the server table.

Once it is properly setup, you can alter the table to the engine of your choice, and a local copy will be made. (e.g. ALTER TABLE my_data ENGINE=InnoDB; )

This have to be done on a per table basis, though.
Sign Up Login You must be logged in to post a comment.