MySQL 5.6 -> 5.7 병렬복제

장비교체 하면서 MySQL 5.6 -> 5.7로 업그레이드 할 일이 생겼다.

 

자~ 계획을 세워보자 

(누구나 계획은 있지...)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5.6 복제세트에 5.7 복제세트를 붙여서 업그레이드

여기서 문제가 될만한것을 생각해보자

 

1. 5.7 부터 기본 캐릭터셋이 utf8mb4 로 바뀌었다.

   5.6 (utf8) -> 5.7 (utf8mb4) 로 복제를 걸때 다른 캐릭터셋으로 연결되면서 오류가 발생한다. 

   이를 해결하기 위해 global slave_type_conversions=ALL_NON_LOSSY 를 적용해주면 된다. 

   이부분은 캐릭터셋을 utf8mb4로  바꿀때만 적용된다. utf8을 그대로 사용할 경우 아무 문제 없다.

 

2. 5.6 (utf8) 3byte ->  5.7 (utf8mb4) 4byte 로 변경되면서 컬럼사이즈가 varcahr 로는 max 수치가 오버되는 경우가 있다. 

 

3. 5.7 에서 sql_mode에 ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES 가 기본으로 적용되었다.
   5.6 에서는 SQL 표준문법이 아니더라도 실행은 되었지만 5.7 에서는 에러가 발생하는 쿼리 확인이 필요하다.
   - ONLY_FULL_GROUP_BY : group by 하지 않은 열을 select 할 수 없다. 
   - STRICT_TRANS_TABLES : 형식이 맞지 않는 값을 insert 할때, 예전에는 warning 이 뜨고 그냥 입력되었지만 5.7부터는 에러가 발생한다.

 

자 이제 복제를 걸어보자. 

원본 DB에서 xtrabackup 을 받아서 신규 DB에 복원하고 복제를 걸면된다. (상세한 설명은 생략한다.)

 

잘된다. 싶었는데.. 문제가 생겼다. 

복제가.. 밀린다! 복제 지연 발생.

 

해결방법은.. LOGICAL_CLOCK 방식의 병렬복제 (Multi-Threaded Slave, MTS) 를 적용해 보자. (적용 방법 생략)

아!! 안된다. ㅡ_ㅡ);;;

 

slave_parallel_workers 를 4개를 잡아도 1넘만 일한다.

mysql> select Id, Master_log_name, Master_log_pos from slave_worker_info;
+----+------------------+----------------+
| Id | Master_log_name  | Master_log_pos |
+----+------------------+----------------+
|  1 | mysql-bin.000011 |     1920310192 |
|  2 |                  |              0 |
|  3 |                  |              0 |
|  4 |                  |              0 |
+----+------------------+----------------+

 

어라어라 왜? 안되지?

 

당연히 안되는거다.. 

 

slave_parallel_type을 logical_clock 으로 적용하기 위해서는 Master 에 binlog_transaction_dependency_tracking 을 적용해야 되는데 5.6 에는 이 파라미터가 없다. 

dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_parallel_type

 

어쩔수 없지 병렬복제는 포기하고 복제지연을 해결할 방법은 5.7 Master 에 적용된 log_slave_updates 옵션을 해제하고 

아래와 같이 구축하고 점검시에 5.7 서버 2대를 Master/Slave로 구성한다. 

log_slave_updates 활성시에 relay log 에 기록된 내용을 binlog 에도 저장해야되니 I/O가 2개가 되서 복제 지연이 발생할 수도 있다.

아래와 같이 구축하고 나서 복제지연은 해결되었다.