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


MySQL 5.6 リファレンスマニュアル  /  InnoDB ストレージエンジン  /  InnoDB と MySQL レプリケーション

14.17 InnoDB と MySQL レプリケーション

MySQL レプリケーションは、MyISAM テーブルに対して機能するのと同じように、InnoDB テーブルに対して機能します。また、スレーブ上のストレージエンジンがマスター上の元のストレージエンジンと同じではない状況でレプリケーションを使用することもできます。たとえば、マスター上の InnoDB テーブルへの変更をスレーブ上の MyISAM テーブルにレプリケートできます。

マスターに対して新しいスレーブを設定するには、InnoDB テーブルスペースとログファイルに加えて InnoDB テーブルの .frm ファイルのコピーを作成し、それらのコピーをスレーブに移動します。innodb_file_per_table オプションが有効になっている場合は、.ibd ファイルもコピーします。これを行うための正しい手順については、セクション14.16「InnoDB のバックアップとリカバリ」を参照してください。

マスターまたは既存のスレーブを停止することなく新しいスレーブを作成するには、MySQL Enterprise Backup 製品を使用します。マスターまたは既存のスレーブをシャットダウンできる場合は、InnoDB テーブルスペースとログファイルのコールドバックアップを作成し、それを使用してスレーブを設定します。

マスター上で失敗したトランザクションがレプリケーションに影響を与えることはありません。MySQL レプリケーションは、データを変更する SQL ステートメントが MySQL によって書き込まれたバイナリログに基づいています。失敗したトランザクション (たとえば、外部キーの違反のため、またはロールバックされているため) はバイナリログに書き込まれないため、スレーブには送信されません。セクション13.3.1「START TRANSACTION、COMMIT、および ROLLBACK 構文」を参照してください。

レプリケーションと CASCADE  マスター上の InnoDB テーブルに関するカスケードアクションは、外部キー関係を共有しているテーブルがマスターとスレーブの両方で InnoDB を使用している場合にのみスレーブにレプリケートされます。これは、ステートメントベースのレプリケーションと行ベースのレプリケーションのどちらを使用している場合にも当てはまります。レプリケーションを開始したあと、次の CREATE TABLE ステートメントを使用してマスター上に 2 つのテーブルを作成したとします。

CREATE TABLE fc1 (
    i INT PRIMARY KEY,
    j INT
) ENGINE = InnoDB;

CREATE TABLE fc2 (
    m INT PRIMARY KEY,
    n INT,
    FOREIGN KEY ni (n) REFERENCES fc1 (i)
        ON DELETE CASCADE
) ENGINE = InnoDB;

このスレーブでは InnoDB のサポートが有効になっていないと仮定します。この場合、スレーブ上にテーブルは作成されますが、それらのテーブルは MyISAM ストレージエンジンを使用し、FOREIGN KEY オプションは無視されます。次に、マスター上のテーブルに何行か挿入します。

master> INSERT INTO fc1 VALUES (1, 1), (2, 2);
Query OK, 2 rows affected (0.09 sec)
Records: 2  Duplicates: 0  Warnings: 0

master> INSERT INTO fc2 VALUES (1, 1), (2, 2), (3, 1);
Query OK, 3 rows affected (0.19 sec)
Records: 3  Duplicates: 0  Warnings: 0

この時点では、次に示すように、マスターとスレーブの両方で、テーブル fc1 には 2 行が含まれ、テーブル fc2 には 3 行が含まれています。

master> SELECT * FROM fc1;
+---+------+
| i | j    |
+---+------+
| 1 |    1 |
| 2 |    2 |
+---+------+
2 rows in set (0.00 sec)

master> SELECT * FROM fc2;
+---+------+
| m | n    |
+---+------+
| 1 |    1 |
| 2 |    2 |
| 3 |    1 |
+---+------+
3 rows in set (0.00 sec)

slave> SELECT * FROM fc1;
+---+------+
| i | j    |
+---+------+
| 1 |    1 |
| 2 |    2 |
+---+------+
2 rows in set (0.00 sec)

slave> SELECT * FROM fc2;
+---+------+
| m | n    |
+---+------+
| 1 |    1 |
| 2 |    2 |
| 3 |    1 |
+---+------+
3 rows in set (0.00 sec)

ここで、マスター上で次の DELETE ステートメントを実行したとします。

master> DELETE FROM fc1 WHERE i=1;
Query OK, 1 row affected (0.09 sec)

カスケードのために、マスター上のテーブル fc2 には 1 行しか含まれなくなりました。

master> SELECT * FROM fc2;
+---+---+
| m | n |
+---+---+
| 2 | 2 |
+---+---+
1 row in set (0.00 sec)

ただし、スレーブでは fc1 に対する DELETE によって fc2 から行が削除されないため、カスケードはスレーブに伝播されません。スレーブの fc2 のコピーには引き続き、最初に挿入されたすべての行が含まれています。

slave> SELECT * FROM fc2;
+---+---+
| m | n |
+---+---+
| 1 | 1 |
| 3 | 1 |
| 2 | 2 |
+---+---+
3 rows in set (0.00 sec)

この違いは、カスケード削除が、実際には InnoDB ストレージエンジンによって内部的に処理されることから来ています。つまり、どの変更もログに記録されません。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.