Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
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
Sign Up Login You must be logged in to post a comment.