MySQL 마스터-슬레이브 복제 실습 - GTID 기반 복제 코드 공유

이 글에서는 주로 MySQL 마스터-슬레이브 복제 방법을 소개합니다. GTID 기반 복제는 MySQL 5.6 이후의 새로운 복제 방식입니다.

GTID 기반 복제

소개

GTID 기반 복제는 MySQL 5.6 이후의 새로운 복제 방식입니다.

GTID(Global Transaction Identifier)는 메인 데이터베이스에 제출된 각 트랜잭션이 클러스터에서 고유한 ID를 갖도록 보장하는 글로벌 트랜잭션 ID입니다.

원본 로그 기반 복제에서는 , 슬레이브 라이브러리는 증분 동기화를 수행할 오프셋을 마스터 라이브러리에 알려야 합니다. 지정된 오류가 지정되면 데이터가 생략되어 데이터 불일치가 발생합니다.

GTID 기반 복제에서 슬레이브 라이브러리는 inform 메인 라이브러리에서 실행된 트랜잭션의 GTID 값을 알려주면 메인 라이브러리는 실행되지 않은 모든 트랜잭션의 GTID 목록을 슬레이브 라이브러리에 반환하고 동일한 트랜잭션이 한 번만 실행되도록 할 수 있습니다. 지정된 슬레이브 라이브러리에서

실전 전투

1. 마스터 데이터베이스에 복제 계정을 생성하고 권한을 부여합니다

GTID 기반 복제는 슬레이브 데이터베이스의 데이터를 슬레이브 데이터베이스로 자동 복사하므로 실행된 트랜잭션이 재생되므로 다른 슬레이브 라이브러리에 동일한 계정을 생성하면 복제 링크 오류가 발생할 수 있습니다. .

mysql> create user 'repl'@'172.%' identified by '123456';

특정 비밀번호 강도를 달성하려면 프로덕션의 비밀번호가 관련 표준화를 따라야 하며, 메인 데이터베이스는 슬레이브 데이터베이스의 특정 네트워크 세그먼트에서만 액세스할 수 있다고 규정해야 합니다.

mysql> grant replication slave on *.* to 'repl'@'172.%';

사용자 보기

mysql> select user, host from mysql.user;
+-----------+-----------+
| user  | host  |
+-----------+-----------+
| prontera | %   |
| root  | %   |
| mysql.sys | localhost |
| root  | localhost |
+-----------+-----------+
4 rows in set (0.00 sec)

권한 보기

mysql> show grants for repl@'172.%';
+--------------------------------------------------+
| Grants for repl@172.%       |
+--------------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.%' |
+--------------------------------------------------+
1 row in set (0.00 sec)

2. 기본 데이터베이스 서버 구성

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
binlog_format = row
server_id = 101
gtid_mode = ON
enforce_gtid_consistency = ON
#log_slave_updates = ON

참고: 좋습니다. 로그와 데이터를 분리하는 습관을 들이는 것이 가장 좋습니다.

Enforce_gtid_consistency 활성화한 후에는 다음 명령을 더 이상 사용할 수 없습니다. 🎜>

테이블 만들기... 선택...

mysql> create table dept select * from departments;
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.

실제로는 두 개의 독립적인

이벤트이므로 분할하여 먼저 테이블을 만든 다음 삽입할 수 있습니다. 테이블에 데이터

create temporary table

트랜잭션 내에서 임시 테이블을 생성할 수 없습니다

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> create temporary table dept(id int);
ERROR 1787 (HY000): Statement violates GTID consistency: 
CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. 
These statements are also not allowed in a function or trigger because functions and triggers are also 
considered to be multi-statement transactions.

동일 트랜잭션에서

업데이트트랜잭션 테이블 및 비트랜잭션 테이블(MyISAM)

mysql> CREATE TABLE `dept_innodb` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT);
Query OK, 0 rows affected (0.04 sec)

mysql> CREATE TABLE `dept_myisam` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT) ENGINE = `MyISAM`;
Query OK, 0 rows affected (0.03 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into dept_innodb(id) value(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into dept_myisam(id) value(1);
ERROR 1785 (HY000): Statement violates GTID consistency: 
Updates to non-transactional tables can only be done in either autocommitted statements or 
single-statement transactions, and never in the same statement as updates to transactional tables.

따라서 기본 데이터베이스 엔진으로 Innodb를 선택하는 것이 좋습니다.

log_slave_updates 이 옵션은 MySQL 5.6 버전에서 GTID 기반 복제에 필요하지만, 슬레이브 서버의 IO 부하를 증가시킵니다. , MySQL 5.7에서는 이 옵션이 더 이상 필요하지 않습니다.

3. 슬레이브 서버

master_info_repository 및 Relay_log_info_repository

를 구성합니다. MySQL 5.6.2 이전에는 슬레이브가 기록한 마스터 정보와 슬레이브 애플리케이션의 binlog 정보는 master.info, Relay-log.info라는 파일에 저장되어 있다. 버전 5.6.2 이후에는 테이블에 기록하는 것이 허용된다. 해당 테이블은 mysql.slave_master_info이다. mysql.slave_relay_log_info, 이 두 테이블은 innodb 엔진 테이블입니다.

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
server_id = 102
# slaves
relay_log  = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
relay_log_info_file = /var/log/mysql/relay-bin.info
enforce_gtid_consistency = ON
log_slave_updates = ON
read_only = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE

4. 슬레이브 데이터 초기화 - [선택]

마스터 라이브러리에 데이터를 백업합니다. first

코드는 다음과 같습니다.

mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases --events -u root -p > backup.sql

—master-data=2 이 옵션은 현재 서버의 binlog 위치와 파일 이름을 출력 파일에 추가합니다(마스터 상태 표시). 1이면 오프셋이 CHANGE MASTER 명령에 접합됩니다. 2이면 출력 오프셋 정보가 주석 처리됩니다.

--all-databases GTID 기반 복제는 모든 트랜잭션을 기록하므로 전체 덤프를 빌드하는 데 이 옵션을 권장합니다.

일반적인 오류

데이터베이스에서 SQL을 가져오면

이 나타납니다. 코드는 다음과 같습니다.

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

이때 데이터베이스에서 MySQL 명령줄을 입력하고 마스터 재설정

을 사용합니다.

5. GTID 기반 복제를 시작합니다

기존 master@172.20.0.2 및slave@172.20.0.3, 이제 mysqldump를 통해 슬레이브 데이터베이스 슬레이브에 데이터가 동기화되었습니다. serverslave 복제 링크 구성

mysql> change master to master_host='master', master_user='repl', master_password='123456', master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.06 sec)

복제 시작

mysql> start slave;

성공적인 시작 후 슬레이브의

상태

mysql> show slave status\G
*************************** 1. row ***************************
    Slave_IO_State: Queueing master event to the relay log
     Master_Host: master
     Master_User: repl
     Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000002
   Read_Master_Log_Pos: 12793692
    Relay_Log_File: relay-bin.000002
    Relay_Log_Pos: 1027
  Relay_Master_Log_File: mysql-bin.000002
    Slave_IO_Running: Yes
   Slave_SQL_Running: Yes
    Replicate_Do_DB:
   Replicate_Ignore_DB:
   Replicate_Do_Table:
  Replicate_Ignore_Table:
  Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
     Last_Errno: 0
     Last_Error:
     Skip_Counter: 0
   Exec_Master_Log_Pos: 814
    Relay_Log_Space: 12794106
    Until_Condition: None
    Until_Log_File:
    Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
    Master_SSL_Cert:
   Master_SSL_Cipher:
    Master_SSL_Key:
  Seconds_Behind_Master: 5096
Master_SSL_Verify_Server_Cert: No
    Last_IO_Errno: 0
    Last_IO_Error:
    Last_SQL_Errno: 0
    Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
    Master_Server_Id: 101
     Master_UUID: a9fd4765-ec70-11e6-b543-0242ac140002
    Master_Info_File: mysql.slave_master_info
     SQL_Delay: 0
   SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Reading event from the relay log
   Master_Retry_Count: 86400
     Master_Bind:
  Last_IO_Error_Timestamp:
  Last_SQL_Error_Timestamp:
    Master_SSL_Crl:
   Master_SSL_Crlpath:
   Retrieved_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-39
   Executed_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-4
    Auto_Position: 1
   Replicate_Rewrite_DB:
     Channel_Name:
   Master_TLS_Version:
1 row in set (0.00 sec)

를 확인합니다. Slave_IO_Running, Slave_SQL_Running이 YES이면,

그리고 Slave_SQL_Running_State는 Slave가 모든 릴레이 로그를 읽었으며 추가 업데이트를 기다리는 중입니다. 이는 복제 링크가 성공적으로 구성되었음을 의미합니다

6. 장점

로그 오프셋을 수동으로 설정할 필요가 없기 때문에 손쉽게 Failover를 수행할 수 있다

1. log_slave_updates인 경우 활성화되면 슬레이브 데이터베이스가 작동하지 않습니다. 기본 데이터베이스의 모든 수정 사항이 손실됩니다

2. 단점

SQL 실행에 제약이 있습니다

1. MySQL 5.6 이후 버전만 지원하며, 5.6 이전 버전은 사용을 권장하지 않습니다

위 내용은 MySQL 마스터-슬레이브 복제 실습 - GTID 기반 복제 코드 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!