먼저 GTID가 무엇인지 살펴보겠습니다.
GTID(Global Transaction ID)는 제출된 거래의 번호이며 전 세계적으로 고유한 번호입니다.
GTID는 실제로 UUID+TID로 구성됩니다. 여기서 UUID는 MySQL 인스턴스의 고유 식별자입니다. TID는 이 인스턴스에서 커밋된 트랜잭션 수를 나타내며 트랜잭션이 커밋됨에 따라 단조롭게 증가합니다. GTID를 기반으로 트랜잭션이 원래 제출된 인스턴스를 알 수 있으며 장애 조치가 용이해집니다.
다음으로 GTID 모드에서 슬레이브를 빠르게 추가하는 방법을 살펴보겠습니다.
GTID 복제가 없기 전에는 MySQL 복제가 바이너리 로그와 위치를 기반으로 했다는 것을 알고 있습니다. 이전 복제에서 다음 변경 문을 실행합니다.
CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='*****',MASTER_LOG_FILE='mysqlbinlog.000003',MASTER_LOG_POS=99721204;
그리고 GTID에서 다음 변경 문을 실행할 수 있습니다.
CHANGE MASTER TO MASTER_HOST='****', MASTER_USER='repl', MASTER_PASSWORD='******', MASTER_PORT=3306, master_auto_position=1;
우리는 할 수 있다 기본적으로 원래 바이너리 로그 방법은 복제를 지정할 때 MASTER_LOG_FILE 및 MASTER_LOG_POS를 지정해야 하지만 GTID 복제는 이러한 매개변수를 알 필요가 없습니다.
GTID 모드에서 마스터-슬레이브 복제를 생성하는 방법을 살펴보겠습니다.
위에서 볼 수 있듯이 GTID 모드에서는 더 이상 MASTER_LOG_FILE 및 MASTER_LOG_POS 두 매개변수를 알 필요가 없습니다. 마스터를 지정하기만 하면 됩니다. 복사본을 만드는 것이 훨씬 간단합니다. GTID 모드에서는 다음 두 개의 전역 변수를 알아야 합니다.
root@perconatest09:23:44>show global variables like 'GTID_%'\G*************************** 1. row ***************************Variable_name: gtid_executed Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24*************************** 2. row ***************************Variable_name: gtid_executed_compression_period Value: 1000*************************** 3. row ***************************Variable_name: gtid_mode Value: ON*************************** 4. row ***************************Variable_name: gtid_owned Value:*************************** 5. row ***************************Variable_name: gtid_purged Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-12
에서 삭제 하는 항목의 GTID 시퀀스 번호를 나타냅니다. 일부 관리를 용이하게 하기 위해 수동으로 설정할 수 있습니다.
이 두 가지 매개 변수를 이해한 후 GTID 복제를 통해 슬레이브 데이터베이스를 추가하는 방법을 살펴보겠습니다. (1): 마스터 데이터베이스에서 전체 백업을 만들고 마스터 백업 시점에 실행된 gtid_executed를 기록합니다. 데이터베이스 (2): 라이브러리에서 복구하고 라이브러리에서 gtid_purged를 첫 번째 단계에서 얻은 마스터의 gtid_executed로 설정합니다. (3): CHANGE MASTER 문을 실행합니다. 우리는mysqldump를 사용하여 기본 데이터베이스를 백업하고 백업을 슬레이브 데이터베이스인 새 머신에 복원합니다. 실행하기 전에 메인 라이브러리에서 매개변수를 살펴보세요:
root@perconatest09:23:58>show global variables like 'GTID_e%'\G*************************** 1. row ***************************Variable_name: gtid_executed Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-242 rows in set (0.01 sec) root@perconatest09:41:33>show global variables like 'GTID_p%'\G*************************** 1. row ***************************Variable_name: gtid_purged Value: 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-121 row in set (0.01 sec)
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=18675 --user=root--p > /home/sa/backup.sql
백업 파일을 살펴볼 수 있습니다:
[root@localhost sa]# head -30 backup.sql
SET @@GLOBAL.GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
즉, 언제 복구를 수행하면 GTID_PURGED가 자동으로 설정되고 이 값은 마스터의 gtid_executed가 되므로 기본적으로 라이브러리에서 복원한 후에는 이를 지정할 필요가 없습니다. 데이터베이스에서 데이터 복구를 입력하세요: source backup.sql;GTID_PURGE 값을 지정할 필요가 없다는 것을 알고 있습니다. 확실하지 않은 경우 확인할 수 있습니다.
show global variables like 'gtid_executed'; show global variables like 'gtid_purged';
나중에 사본을 직접 지정하세요.
CHANGE MASTER TO MASTER_HOST="***", MASTER_USER="root", MASTER_PASSWORD="*****", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;
reset 및 기타 작업이 수행되면 슬레이브 라이브러리에 다음 오류가 발생합니다.
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.'
root@perconatest09:41:38>show global variables like 'GTID_EXECUTED';+---------------+---------------------------------------------------------------------------------------------------------------------------------+| Variable_name | Value |+---------------+---------------------------------------------------------------------------------------------------------------------------------+| gtid_executed | 5031589f-3551-11e7-89a0-00505693235d:1-12, 806ede0c-357e-11e7-9719-00505693235d:1-11, a38c33ee-34b7-11e7-ae1d-005056931959:1-24 |+---------------+---------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.01 sec)
root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
root@(none)03:04:49>reset master; root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24'; root@(none)03:04:49>start slave; root@(none)03:04:49>show slave status\G
이렇게 하면 수리가 완료되지만 최종적으로 마스터-슬레이브 데이터의 일관성을 확인하기 위해 체크섬을 사용하는 것이 가장 좋습니다. 오류 메시지:
바이너리 로그에서 데이터를 읽을 때 마스터에서 치명적인 오류 1236이 발생했습니다. '슬레이브는 CHANGE MASTER TO MASTER_AUTO_POSITION = 1을 사용하여 연결하고 있지만 마스터는 슬레이브에 필요한 GTID가 포함된 바이너리 로그를 삭제했습니다
(오류 메시지 게시 조회수를 늘려주세요
물론 위의 방법이 데이터의 완전한 일관성을 보장하지는 않습니다. pt-table-checksum과 pt-table-sync를 사용하여 검증해야 하지만 이것이 반드시 가장 높거나 높은 것은 아닙니다. 앞서 소개한 방법은 전체 백업을 한 후 복원하고 마스터를 지정하는 방법입니다.
위 내용은 GTID 복제 및 문제 처리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!