MySQL Master-Slave Replication Setup을 생성하고 문제를 해결하는 가장 좋은 방법은 무엇입니까?

데이터베이스 관리를 처음 사용합니다.

mysql master-slave replication을 설정하는 동안 많은 문제가 있습니다.

또한 정기적 인 mysql 복제 문제 해결 문제에 직면 해 있습니다.

아무도 내가이 모든 것을 어떻게 다루어야하는지 이해하도록 도울 수 있습니까?

튜토리얼에 대한 링크를 제공했습니다. 우분투에서 my.cnf 파일은 howtoforge 튜토리얼처럼 /etc/my.cnf가 아니라 /etc/mysql/my.cnf에 있습니다. 설정에서 FLUSH TABLES WITH READ LOCK을 사용하지 않았습니다. 마스터에. 마스터 서버에 쓰기 작업이 많은 경우 백업하기 전에 해당 명령을 실행하여 테이블을 잠 가야 할 수도 있습니다. FLUSH TABLES WITH READ LOCK;을 사용한 경우 백업 후에 UNLOCK TABLES를 실행하려고합니다. 문제가 발생하면 알려주십시오.

다음은 Redhat / CentOS 용으로 만든 howto forge에 대한 튜토리얼입니다. http://www.howtoforge.com/mysql_database_replication

우분투에서 잘 보인 또 다른 튜토리얼 http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

내가 사용한 구성은 다음과 같습니다.

MASTER 서버에서

마스터 서버를 구성하십시오.

vi /etc/mysql/my.cnf

[mysqld]

# bind-address = 127.0.0.1 (comment this out)
server_id           = 1
log_bin             = /var/log/mysql/mysql-bin.log
log_bin_index       = /var/log/mysql/mysql-bin.log.index
max_binlog_size     = 100M
expire_logs_days    = 1

MySQL을 다시 시작하십시오.

/etc/init.d/mysql restart

mysql의 콘솔에 연결하십시오 : mysql -u root -ppassword

복제 사용자에게 권한을 작성하고 부여하십시오.

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'ipaddressofslave' IDENTIFIED BY 'replicationuserpassword';

이 정보를 어딘가에 복사하거나 보이도록하십시오

SHOW MASTER STATUS \G;
mysql> show master status \G;
            File: mysql-bin.000001
        Position: 100
    Binlog_Do_DB: 
Binlog_Ignore_DB:

mysql> quit 

데이터베이스를 파일로 덤프하십시오.

mysqldump -u root -p databasename > /tmp/databasename-backup.sql

scp를 사용하여 데이터베이스 덤프를 슬레이브 서버에 복사하거나 원하는 경우 ftp를 사용하십시오.

scp /tmp/databasename-backup.sql root@ipaddressofslave:/tmp/

SLAVE 서버에서

mysql 구성을 편집하십시오.

vi /etc/mysql/my.cnf
[mysqld]

# slave server configuration
server_id           = 2

# this is optional, but I find it useful to specify where the relay logs go to control.  
# Don't forget to create the /var/log/mysql directory and give mysql rights to it.  
# chown mysql:mysql -R /var/log/mysql
# disk space
relay_log           = /var/log/mysql/mysql-relay-bin
relay_log_index     = /var/log/mysql/mysql-relay-bin.index
relay_log_space_limit = 2000M

MySQL을 다시 시작하십시오. /etc/init.d/mysql restart

백업을 복원하십시오.

mysql -u root -ppassword nameofthedatabase < /tmp/databasename-backup.sql

MySQL에 연결

mysql -u root -ppassword

stop slave;

# master log file and master_log_pos taken from show master status above
CHANGE MASTER TO master_host='ipaddressmaster', master_port=3306, master_user='replication', master_password='replicationuserpassword', master_log_file='mysql-bin.000001', master_log_pos=100;

start slave;

실행 SHOW SLAVE STATUS\G:

mysql> show slave status\G;
             Slave_IO_State: Waiting for master to send event
                Master_Host: ipaddressmaster
                Master_User: replication
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.0000001
        Read_Master_Log_Pos: 100
             Relay_Log_File: mysql-relay-bin.000001
              Relay_Log_Pos: 1
      Relay_Master_Log_File: mysql-bin.000001
           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: 17324288
            Relay_Log_Space: 17324425
            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
1 row in set (0.02 sec)

나중에 여러 가지 이유로 복제가 실패 할 수 있습니다. 슬레이브에서는 SHOW SLAVE STATUS \ G; 명령을 실행하여 상태를 모니터링 할 수 있습니다. 또는 크론 작업을 설정하여 상태를 모니터하고 실패하면 이메일을 보내십시오. 이 명령의 출력으로 패밀리를 가져옵니다. 복제가 올바르게 실행 중이면 "Slave_IO_State : 마스터가 이벤트를 기다리는 중"이 표시됩니다.

이 설정이 올바르게 완료되면 해당 복제를 모니터링하는 스크립트를 제공 할 수 있습니다.

다음은 MySQL에서 오류 로그를 모니터링하는 스크립트입니다. 라인을 추가하면

[mysqld]

로그 오류 = /var/log/mysql/mysql.err

mysql 재시작 : /etc/init.d/mysql restart

그런 다음 다음 스크립트를 사용하여 로그 파일을 모니터 할 수 있습니다. 로그가 어떤 식 으로든 변경되면 슬레이브 서버에서 오류가 발생했음을 알리는 이메일이 발송됩니다. 오류 로그를 정기적으로 확인하려면이 스크립트를 crontab에 추가해야합니다.

다음은 샘플 스크립트입니다. /somepath/monitor_mysql_log.sh

#! /bin/sh
MAIL_TO="addressemail@something.com"

# This is the log that will be monitored.
# If any changes occur to this, then take appropriate action.
MONITORED_LOG=/var/log/mysql/mysql.err

# We will need this log to see whether any changes occured to /tmp/goreb.log
TEMP_LOG=/tmp/.mysql.err.1

# This is a 1-time command i.e. create the log file if it does nto exist.
[ ! -f $TEMP_LOG ] && touch -r $MONITORED_LOG $TEMP_LOG

[ $MONITORED_LOG -nt $TEMP_LOG ] && echo "an error occurred in mysql" | mail -s "Error on MySQL" $MAILTO

# Update $TEMP_LOG with the new modified date of $MONITORED_LOG
touch -r $MONITORED_LOG $TEMP_LOG

crontab에 추가합니다.

스크립트를 실행 가능하게 만드십시오.

chmod +x /somepath/monitor_mysql_log.sh

crontab 업데이트 :

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

그리고 스크립트는 1 분마다 실행됩니다.

내가 제공 한 스크립트는 방금 정리 한 스크립트입니다. 또한 서버에서 이메일을 보내려면 postfix 또는 sendmail과 같은 것을 설치해야합니다.

Mysqldump는 빠르지 만 큰 DB의 경우 덤프 복원이 매우 느릴 수 있으며 라이브 사이트에서는 잠금 테이블을 사용할 수 없습니다. 슬레이브를 설정하는 훨씬 더 좋고 빠른 방법은 Percona의 XtraBackup 을 사용하는 것 입니다. XtraBackup은 마스터에 적은 부하를 가하고 잠금이 필요하지 않으며 슬레이브의 복원이 매우 빠릅니다. 이 메커니즘은 사용자 테이블과 같은 것을 포함하여 전체 데이터베이스의 완전한 복제본을 생성하는데, 이는 debian-sys-maint 사용자와 같이 주식 설치에 의해 설정된 일부 항목을 손상시킵니다. 반드시 나쁜 것은 아닙니다. !

보너스로이를 수행하는 방법을 알고 나면 매일 백업에 대해 정확히 동일한 메커니즘을 사용할 수 있습니다. 백업은 mysqldump보다 느리지 만 복원 속도는 훨씬 빠릅니다. 이는 공황 상태에 있고 백업을 복원해야하는 상황에 필요한 것입니다! 중대한 복제 오류가 발생하면이 절차를 사용하여 슬레이브를 폐기하고 재 구축하십시오. 실제로 오래 걸리지 않습니다.

배포판에 Percona의 apt / yum repo 를 설정 한 다음 xtrabackup마스터 및 슬레이브 모두에 ​​패키지 를 설치해야합니다 . 또한 백업 속도와 큰 차이가 있기 때문에 pigz 압축 유틸리티 (대부분의 표준 저장소 에서 사용 가능한 병렬 gzip)를 사용하는 것이 좋습니다 .

프로세스는 다음과 같이 진행되며 (우분투에서는 다른 배포판이 약간 다를 수 있음) 이미 슬레이브에 MySQL을 설치했다고 가정합니다.

1. 먼저 마스터에서 백업을 수행합니다 mkdir -p /var/xtrabackup; /usr/bin/innobackupex --slave-info --stream=tar --throttle=1500 /var/xtrabackup 2> /tmp/xtrabackup.out | /usr/bin/pigz -p 4 -c --best -q > /var/backups/mysql.tgz(스로틀 값을 조정하여 백업이 라이브 서비스에 미치는 영향을 제한 함)
2. 백업 파일을 슬레이브에 복사합니다 ( scp -l 400000라이브 클라이언트의 네트워크 대역폭 마스터를 사용 하지 않기 위해 사용 )
3. 슬레이브에서 mysql을 중지하십시오. service mysql stop
4. 이전 MySQL 데이터 디렉토리를 방해 mv /var/lib/mysql /var/lib/mysql2하지 마십시오 (또는 디스크 공간이 부족하면 압축하십시오)
5. 새 데이터 디렉토리를 작성하고 이동하십시오. mkdir /var/lib/mysql; cd /var/lib/mysql
6. 백업 파일을 새 폴더에 압축을 풉니 다 : tar xvzif /path/to/backup/mysql.tgz. tar 작업 의 i옵션에 유의하십시오. 옵션이 없으면 작동하지 않습니다 . DB가 큰 경우 시간이 걸립니다.
7. 추출 된 파일에서 Innobackupex 도구를 실행하십시오 /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql. 이진 로그에서 파일에 대한 충돌 복구를 효과적으로 실행합니다. 몇 초 밖에 걸리지 않습니다. 작은 서버에서는 더 적은 메모리 양을 사용하십시오.
8. 성공적으로 완료되었다고 가정하면 백업을 삭제하고 파일의 소유권을 설정하십시오. rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
9. mysql을 시작하십시오 : service mysql start
10. 마스터 로그 파일 이름과 백업 위치를 가져옵니다 (xtrabackup_slave_info의 정보가 아님) : cat xtrabackup_binlog_info. 그것은 같은 것을 말할 것입니다mysql-bin.000916 13889427
11. MySQL에 연결하고 물건이 있는지 확인하십시오.
12. 로그에 대한 세부 정보를 사용하여 복제 설정을 재설정하십시오. CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000916', MASTER_LOG_POS=13889427;(실제 DB 서버 세부 정보와 일치하도록 변경)
13. 슬레이브를 다시 시작하십시오. START SLAVE;
14. 'seconds_behind_master'가 0이 될 때까지 슬레이브가 마스터를 따라 잡을 때 슬레이브의 상태를 확인하십시오. SHOW SLAVE STATUS\G

이제 노예가 모두 설정되었습니다. 필요한 경우 이제 순환 복제를 설정할 수 있습니다.

1. 슬레이브에서 : FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;로그 파일 이름과 위치를 확인하십시오 (mysql-bin.000031 및 17244785와 같은 것).
2. 마스터에서 : CHANGE MASTER TO MASTER_HOST='192.168.0.2', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000031', MASTER_LOG_POS=17244785;방금 살펴본 슬레이브에서 값을 삽입합니다.
3. 마스터에서 : START SLAVE;
4. 노예에서 : UNLOCK TABLES;

이제 모두 순환 복제로 설정해야합니다.

문제 해결이 진행되는 한 Percona의 툴킷 에는 자동 손상, 지연 측정 등을 파악하기위한 체크섬과 같은 모든 종류 의 도구 가 있습니다. binlog_format = MIXEDmy.cnf에서 설정하면 가장 일반적인 형태의 복제 손상을 피할 수 있습니다 . 내 경험에 따르면 복제는 일반적으로 번거롭지 않습니다.