17.19 InnoDB and MySQL Replication

17.19 InnoDB and MySQL Replication

replication을 사용할 때 replica에서의 스토리지 엔진이 source에서의 스토리지 엔진과 동일하지 않게 설정하는 것도 가능합니다. 예를 들어, source의 InnoDB 테이블에 대한 변경을 replica의 MyISAM 테이블로 replication할 수 있습니다. 더 많은 정보는 Section 19.4.4, “Using Replication with Different Source and Replica Storage Engines”를 참조하십시오.

replica 설정에 대한 정보는 Section 19.1.2.6, “Setting Up Replicas”와 Section 19.1.2.5, “Choosing a Method for Data Snapshots”를 참조하십시오. source나 기존 replica를 중단하지 않고 새로운 replica를 만들려면 MySQL Enterprise Backup product를 사용하십시오.

source에서 실패한 트랜잭션은 replication에 영향을 주지 않습니다. MySQL replication은 바이너리 로그를 기반으로 동작하며, MySQL은 데이터 변경을 수행하는 SQL 문들을 이 바이너리 로그에 기록합니다. 실패한 트랜잭션(예를 들어 외래 키 위반 때문에, 혹은 롤백되었기 때문에 실패한 트랜잭션)은 바이너리 로그에 기록되지 않으므로 replica로 전송되지 않습니다. Section 15.3.1, “START TRANSACTION, COMMIT, and ROLLBACK Statements”를 참조하십시오.

Replication and CASCADE.

source의 InnoDB 테이블에 대한 cascade 동작은 외래 키 관계를 공유하는 테이블들이 source와 replica 모두에서 InnoDB를 사용하고 있을 때에만 replica에서 실행됩니다. 이는 statement-based replication을 사용하든 row-based replication을 사용하든 동일하게 적용됩니다. replication을 시작한 후, 다음 CREATE TABLE 문을 사용하여 source에서 두 개의 테이블을 생성한다고 가정해 보겠습니다. 이때 InnoDB는 기본 스토리지 엔진으로 정의되어 있습니다:

1CREATE TABLE fc1 (
2    i INT PRIMARY KEY,
3    j INT
4);
5
6CREATE TABLE fc2 (
7    m INT PRIMARY KEY,
8    n INT,
9    FOREIGN KEY ni (n) REFERENCES fc1 (i)
10        ON DELETE CASCADE
11);

replica에서 MyISAM이 기본 스토리지 엔진으로 정의되어 있다면, replica에서도 동일한 테이블이 생성되지만, MyISAM 스토리지 엔진을 사용하게 되며 FOREIGN KEY 옵션은 무시됩니다. 이제 source의 테이블에 다음과 같이 행을 삽입합니다:

1source> INSERT INTO fc1 VALUES (1, 1), (2, 2);
2Query OK, 2 rows affected (0.09 sec)
3Records: 2  Duplicates: 0  Warnings: 0
4
5source> INSERT INTO fc2 VALUES (1, 1), (2, 2), (3, 1);
6Query OK, 3 rows affected (0.19 sec)
7Records: 3  Duplicates: 0  Warnings: 0

이 시점에서, source와 replica 모두에서 테이블 fc1에는 2개의 행이 있고, fc2에는 아래와 같이 3개의 행이 들어 있습니다:

1source> SELECT * FROM fc1;
2+---+------+
3| i | j    |
4+---+------+
5| 1 |    1 |
6| 2 |    2 |
7+---+------+
82 rows in set (0.00 sec)
9
10source> SELECT * FROM fc2;
11+---+------+
12| m | n    |
13+---+------+
14| 1 |    1 |
15| 2 |    2 |
16| 3 |    1 |
17+---+------+
183 rows in set (0.00 sec)
19
20replica> SELECT * FROM fc1;
21+---+------+
22| i | j    |
23+---+------+
24| 1 |    1 |
25| 2 |    2 |
26+---+------+
272 rows in set (0.00 sec)
28
29replica> SELECT * FROM fc2;
30+---+------+
31| m | n    |
32+---+------+
33| 1 |    1 |
34| 2 |    2 |
35| 3 |    1 |
36+---+------+
373 rows in set (0.00 sec)

이제 source에서 다음과 같은 DELETE 문을 실행한다고 가정해 보겠습니다:

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

cascade 때문에 source의 테이블 fc2에는 이제 1개의 행만 남게 됩니다:

1source> SELECT * FROM fc2;
2+---+---+
3| m | n |
4+---+---+
5| 2 | 2 |
6+---+---+
71 row in set (0.00 sec)

그러나 replica에서는 cascade가 전파되지 않습니다. 그 이유는 replica에서 fc1에 대한 DELETE가 fc2의 어떤 행도 삭제하지 않기 때문입니다. replica에 있는 fc2의 복사본에는 여전히 처음에 삽입했던 모든 행이 남아 있습니다:

1replica> SELECT * FROM fc2;
2+---+---+
3| m | n |
4+---+---+
5| 1 | 1 |
6| 3 | 1 |
7| 2 | 2 |
8+---+---+
93 rows in set (0.00 sec)

이 차이는 cascading delete가 InnoDB 스토리지 엔진 내부에서 처리되기 때문이며, 이 때문에 해당 변경 내용이 전혀 로그에 기록되지 않는다는 점에서 기인합니다.