MySQL 마스터-슬레이브 복제 실습 - 로그 포인트 기반 복제 코드 예시 상세 설명

이 글은 주로 MySQL 마스터-슬레이브 복제 실습 - 로그 포인트 기반 복제에 대한 자세한 설명을 소개하며, 관심 있는 분들은 참고하시기 바랍니다.

로그 포인트 기반 복제

1. 마스터 및 슬레이브 라이브러리에 전용 복제 계정 설정

MariaDB [employees]> create user 'repl'@'172.%' identified by '123456';

제작 시 비밀번호 주의 관련 특정 비밀번호 강도를 달성하려면 사양을 따라야 하며 마스터 데이터베이스는 슬레이브 데이터베이스의 특정 네트워크 세그먼트에서만 액세스할 수 있도록 규정되어 있습니다

2. 마스터 데이터베이스와 슬레이브에 대한 복사 권한을 부여합니다. 데이터베이스

MariaDB [employees]> grant replication slave on *.* to 'repl'@'172.%';

3. 기본 라이브러리 구성

바이너리 로그를 활성화하려면 서비스를 다시 시작해야 하며, server_id는 명령줄 및 구성과 결합할 수 있는 동적 매개변수입니다. 파일을 사용하면 다시 시작하지 않고 영구적으로 구성할 수 있습니다. 참고 server_id는 클러스터에서 고유합니다.

[mysqld]
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
binlog_format = row
server_id = 101

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

4. 슬레이브 데이터베이스 구성

log_slave_update 옵션은 릴레이 로그를 로컬 binlog에 저장할지 여부를 결정합니다. 링크 복제가 구성된 경우 이 옵션은 필수입니다.

[mysqld]
# replication
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-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
log_slave_updates = ON
read_only

5. 슬레이브 데이터베이스에서 데이터 초기화

여기에서는 Mysqldump를 사용하여 기본 데이터베이스를 백업합니다. 잠금 없는 핫 백업(innodb 엔진 기반)

직원 데이터베이스의 데이터를 기본 데이터베이스에 백업합니다.

코드는 다음과 같습니다.

mysqldump --single-transaction --master-data=1 --triggers --routines --databases employees -u root -p >> backup.sql

백업 파일 backup.sql을 scp 또는 docker 볼륨을 통해 슬레이브 서버에 마운트하고 슬레이브 데이터베이스

mysql -u root -p < backup.sql

로 가져옵니다. 6. 복제 링크 시작

기존 master@172.20.0.2 및 Slave@172.20.0.3, 데이터는 mysqldump를 통해 슬레이브 데이터베이스 슬레이브로 동기화되었습니다. 이제 슬레이브 서버에서 슬레이브에 복제 링크를 구성합니다

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='master', 
MASTER_USER='repl', 
MASTER_PASSWORD='123456', 
MASTER_LOG_FILE='mariadb-bin.000029', 
MASTER_LOG_POS=516;
Query OK, 0 rows affected (0.02 sec)

슬레이브 데이터베이스에서 복제 링크를 시작합니다

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.01 sec)

7. 슬레이브 데이터베이스에서 슬레이브 상태를 확인하세요

Slave_IO_Running과 Slave_SQL_Running이 YES여야 합니다. 오류가 발생하면 Last_IO_Error 또는 Last_SQL_Error의 프롬프트 정보를 자세히 읽어보세요

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
        Slave_IO_State: Waiting for master to send event
         Master_Host: master
         Master_User: repl
         Master_Port: 3306
        Connect_Retry: 60
       Master_Log_File: mariadb-bin.000029
     Read_Master_Log_Pos: 516
        Relay_Log_File: relay-bin.000002
        Relay_Log_Pos: 539
    Relay_Master_Log_File: mariadb-bin.000029
       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: 516
       Relay_Log_Space: 831
       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: 0
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_SSL_Crl:
      Master_SSL_Crlpath:
          Using_Gtid: No
         Gtid_IO_Pos:
   Replicate_Do_Domain_Ids:
 Replicate_Ignore_Domain_Ids:
        Parallel_Mode: conservative
1 row in set (0.00 sec)

8. 메인 라이브러리

에서 덤프 스레드를 확인하여 binlog 덤프 스레드가 올바르게 시작되었는지 확인합니다.

MariaDB [(none)]> show processlist \G
*************************** 1. row ***************************
   Id: 7
  User: root
  Host: 172.20.0.1:41868
   db: employees
 Command: Sleep
  Time: 56
  State:
  Info: NULL
Progress: 0.000
*************************** 2. row ***************************
   Id: 10
  User: repl
  Host: 172.20.0.3:45974
   db: NULL
 Command: Binlog Dump
  Time: 246
  State: Master has sent all binlog to slave; waiting for binlog to be updated
  Info: NULL
Progress: 0.000

2행에서 Binlog Dump 명령이 시작되는 것을 볼 수 있습니다. 복제 스레드가 성공적으로 시작되었음을 증명합니다

9. 요약

장점

1. 기술이 성숙하고 BUG가 상대적으로 적습니다

2. SQL에 제한이 없습니다쿼리. GTID 기반 SQL을 복사할 때 모두 사용할 수는 없습니다
   

단점

1. failover 중 새 기본 데이터베이스의 로그 오프셋 다시 얻기 더 어려움

마스터-다중 슬레이브 환경에서 기존 마스터가 다운된 후 클러스터에서 새 마스터가 선택되면 각 DB의 binlog 이후 다른 슬레이브 라이브러리가 새 마스터를 다시 동기화해야 합니다. 독립적으로 존재하므로 동기화를 시작할 로그 포인트를 찾기가 어렵습니다

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