MySQL 5.6 GTID 새로운 기능 practice_MySQL

GTID 소개

GTID란 무엇인가요

GTID(Global Transaction ID)는 제출된 트랜잭션의 번호로, 전역적으로 고유한 번호입니다.

GTID는 실제로 UUID+TID로 구성됩니다. UUID는 MySQL 인스턴스의 고유 식별자입니다. TID는 이 인스턴스에서 커밋된 트랜잭션 수를 나타내며 트랜잭션이 커밋됨에 따라 단조롭게 증가합니다. 다음은 GTID의 구체적인 형태입니다

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

자세한 소개는 공식문서를 참고하세요

GTID의 역할

그렇다면 GTID 기능의 목적은 무엇인가요? 구체적인 요약에는 주로 다음 두 가지 내용이 포함됩니다.

GTID에 따르면 트랜잭션이 처음 제출된 인스턴스를 알 수 있습니다. GTID가 있으면 복제의 장애 조치가 용이해집니다. 여기서는 두 번째 사항에 대해 자세히 설명합니다. MySQL 5.6의 GTID가 등장하기 전의 복제 장애 조치(failover) 작업 과정을 살펴보겠습니다. 아래와 같은 환경이 있다고 가정합니다

이번에는 A서버의 서버가 다운되어 B서버로 업무를 전환해야 합니다. 동시에 서버 C의 복제 소스를 서버 B로 변경해야 합니다. 복사 소스 수정을 위한 명령 구문은 매우 간단합니다. 즉, CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn입니다. 어려운 점은 동일한 트랜잭션이라도 머신마다 binlog 이름과 위치가 다르기 때문에 현재 서버 C의 동기화 중지 지점과 이에 대응하는 서버 B의 master_log_file, master_log_pos가 무엇인지 찾는 것이 문제가 된다는 점이다. 이는 M-S 복제 클러스터가 MMM 및 MHA와 같은 추가 관리 도구를 사용해야 하는 중요한 이유입니다.

5.6에서 GTID가 등장한 이후에는 이 문제가 매우 간단해 보입니다. 동일한 트랜잭션의 GTID는 모든 노드에서 동일한 값을 갖기 때문에 서버 B의 GTID는 서버 C의 현재 중지 지점의 GTID를 기준으로 고유하게 찾을 수 있습니다. MASTER_AUTO_POSITION 함수의 출현으로 인해 GTID의 구체적인 값을 알 필요가 없으며 CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION 명령을 직접 사용하여 장애 조치 작업을 직접 완료할 수 있습니다. 참 쉽죠?

GTID 기반 마스터-슬레이브 복제 소개

빌드

mysql_sandbox 스크립트를 기반으로 마스터 1개와 슬레이브 3개로 구성된 위치 기반 복제 환경을 먼저 만들었습니다. 그런 다음 구성 수정을 통해 전체 아키텍처가 GTID 기반 복제용으로 설계되었습니다.

공식 MySQL 문서에 제공된 GTID 구성 제안에 따르면. 마스터 및 슬레이브 노드의 구성을 한 번 수정하고 서비스를 다시 시작해야 합니다. 이러한 작업은 프로덕션 환경에서 업그레이드할 때 분명히 허용되지 않습니다. Facebook, Booking.com, Percona는 모두 패치를 통해 이를 최적화하고 더욱 우아한 업그레이드를 달성했습니다. 구체적인 작업 방법은 향후 블로그 게시물에서 소개될 예정입니다. 여기에서는 공식 문서에 따라 실험적인 업그레이드를 수행합니다.

주요 업그레이드 단계는 다음과 같습니다.

마스터에서 my.cnf를 수정하기 위해 새 데이터가 기록되지 않도록 마스터에서 read_only를 구성합니다. 슬레이브에서 my.cnf를 수정하려면 서비스를 다시 시작하세요. master_auto_position=1에서 GTID 기반 복제를 활성화합니다. 실험적인 환경이므로 read_only 및 서비스를 다시 시작하는 것은 큰 문제가 아닙니다. 공식 GTID 구성 권장 사항을 따르면 업그레이드를 성공적으로 완료할 수 있습니다. 자세한 프로세스는 여기에서 설명하지 않습니다. 아래에는 업그레이드 과정에서 쉽게 발생할 수 있는 몇 가지 오류가 나열되어 있습니다.

흔히 저지르는 실수

my.cnf에서는 gtid_mode=ON, log_slave_updates 및 Enforce_gtid_consistency의 세 가지 매개변수를 동시에 구성해야 합니다. 그렇지 않으면 mysql.err

에 다음 오류가 나타납니다.

2016-10-08 20:11:08 32147 [ERROR] --gtid-mode=ON 또는 UPGRADE_STEP_1 또는 UPGRADE_STEP_2에는 --log-bin 및 --log-slave-updates가 필요합니다
2016-10-08 20:13:53 32570 [ERROR] --gtid-mode=ON 또는 UPGRADE_STEP_1에는 --enforce-gtid-consistency가 필요합니다

마스터를 다음으로 변경한 후 경고

문서에 따라 마스터를 으로 변경하면 두 가지 경고가 표시됩니다. 실제로 이는 정상적인 동기화에 영향을 미치지 않는 두 가지 보안 경고입니다(관심 있는 독자는 이 경고의 자세한 소개를 읽을 수 있습니다. 경고의 구체적인 내용은 다음과 같습니다.

slave1 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.03 sec)
slave1 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave1 [localhost] {msandbox} ((none)) > show warnings;
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1759 | Sending passwords in plain text without SSL/TLS is extremely insecure. |
| Note | 1760 | Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

실험 1: 슬레이브가 요구하는 트랜잭션에 해당하는 GTID가 마스터에서 제거된 경우

'%gtid%'와 같은 전역 변수 show 명령 결과에 따르면 GTID와 관련된 변수 중 gtid_purged가 있음을 알 수 있습니다. 문자 그대로의 의미와 공식 문서를 통해 이 변수에 기록된 내용은 로컬 시스템에서 실행되었지만 명령에 대한 바이너리 로그 제거에 의해 정리된 gtid_set임을 알 수 있습니다.
이 섹션에서는 슬레이브가 가져오지 않은 일부 gtid 이벤트를 마스터가 제거하는 경우 어떤 일이 발생하는지 테스트합니다.

다음 명령은 마스터에서 실행됩니다

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+----------------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+----------------------------------------+
7 rows in set (0.01 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test2 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.02 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test3 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.04 sec)
master [localhost] {msandbox} (test) > show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000005 | 359 | | | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
master [localhost] {msandbox} (test) > purge binary logs to 'mysql-bin.000004';
Query OK, 0 rows affected (0.03 sec)
master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave2上重新做一次主从，以下命令在slave2上执行

slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
......
Slave_IO_Running: No
Slave_SQL_Running: Yes
......
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 151
......
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
......
Auto_Position: 1
1 row in set (0.00 sec)

实验二：忽略purged的部分，强行同步

那么实际生产应用当中，偶尔会遇到这样的情况：某个slave从备份恢复后（或者load data infile）后，DBA可以人为保证该slave数据和master一致；或者即使不一致，这些差异也不会导致今后的主从异常（例如：所有master上只有insert没有update）。这样的前提下，我们又想使slave通过replication从master进行数据复制。此时我们就需要跳过master已经被purge的部分，那么实际该如何操作呢？

我们还是以实验一的情况为例：

先确认master上已经purge的部分。从下面的命令结果可以知道master上已经缺失24024e52-bd95-11e4-9c6d-926853670d0b:1这一条事务的相关日志

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

slave2 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';
Query OK, 0 rows affected (0.05 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G 
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
......
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 359
Relay_Log_File: mysql_sandbox21290-relay-bin.000004
Relay_Log_Pos: 569
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Exec_Master_Log_Pos: 359
Relay_Log_Space: 873
......
Master_Server_Id: 1
Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b
Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
......
Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3
Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3
Auto_Position: 1
1 row in set (0.00 sec)

可以看到此时slave已经可以正常同步，并补齐了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范围的binlog日志。

以上所述是小编给大家介绍的MySQL 5.6 GTID新特性实践，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！