MySQL은 복제 프로세스 중 하나의 단방향 및 비동기 복제를 지원합니다. 서버는 마스터 서버 역할을 합니다. 하나 이상의 다른 서버는 슬레이브 서버 역할을 합니다. 마스터 서버는 바이너리 로그 파일에 업데이트를 기록하고 로그 파일의 인덱스를 유지하여 로그 회전을 추적합니다. 슬레이브가 마스터에 연결되면 슬레이브가 로그에서 읽은 마지막 성공적인 업데이트 위치를 마스터에 알립니다. 슬레이브 서버는 그 이후 발생한 모든 업데이트를 수신한 후 마스터 서버가 다음 업데이트를 알리기를 차단하고 기다립니다.
마스터-슬레이브 복제를 사용하는 이유는 무엇입니까?
1. 마스터 서버/슬레이브 서버 설정으로 견고성이 향상되었습니다. 마스터 서버에 문제가 생겼을 때 백업 서버로 슬레이브 서버로 전환할 수 있습니다.
2. 고객 문의 처리 업무를 마스터 서버와 슬레이브 서버로 나누어 고객 응대 시간을 향상시킬 수 있습니다. 하지만 마스터 서버와 슬레이브 서버를 동시에 업데이트하지 마십시오. 충돌이 발생할 수 있습니다.
3. 복제 사용의 또 다른 이점은 슬레이브 서버를 사용하여 마스터 서버를 방해하지 않고 백업을 수행할 수 있다는 것입니다. 마스터 서버는 백업 프로세스 중에 업데이트를 계속 처리할 수 있습니다.
MySQL은 3개의 스레드를 사용하여 복제 기능을 수행합니다(마스터 서버에 1개, 슬레이브 서버에 2개). START SLAVE가 발행되면 슬레이브 서버는 I/O 스레드를 생성하여 마스터 서버에 연결하고 마스터 서버가 Binary를 보내도록 합니다. 마스터 서버는 바이너리 로그의 내용을 슬레이브 서버로 보내기 위해 스레드를 생성합니다. 슬레이브 서버 I/O 스레드는 마스터 서버 Binlog Dump 스레드에서 보낸 내용을 읽고 해당 데이터를 슬레이브의 로컬 파일에 복사합니다. 세 번째 스레드는 SQL 스레드입니다. 슬레이브 서버는 이 스레드를 사용하여 릴레이 로그를 읽고 로그에 포함된 업데이트를 실행하여 마스터 서버에서 발생한 복제를 쿼리합니다. 슬레이브 서버 정보
기본 릴레이 로그는 호스트_이름-릴레이-bin.nnnnnn 형식의 파일 이름을 사용합니다. 여기서 호스트 이름은 슬레이브 서버 호스트 이름이고 nnnnnn은 연속적인 시퀀스 번호로 시작하는 연속 릴레이 로그 파일을 생성합니다. 현재 사용 중인 릴레이 로그를 식별하기 위해 릴레이 로그 인덱스 파일을 추적합니다. 기본적으로 이러한 파일은 슬레이브 서버의 데이터 디렉터리에 생성됩니다. 바이너리 로그와 동일한 형식을 가지며 mysqlbinlog로 읽을 수 있습니다. SQL 스레드가 릴레이 로그의 모든 이벤트를 실행하면 릴레이 로그가
서버에서 자동으로 삭제되고 데이터 디렉터리에 두 개의 추가 상태 파일이 생성됩니다. --master.info 및 Relay-log.info. 상태 파일은 하드 디스크에 저장되며 다음에 슬레이브 서버가 시작될 때 이 파일을 읽어 바이너리 수를 결정합니다. 마스터 서버에서 로그를 읽었으며 자체 릴레이 로그를 처리하는 범위입니다.
마스터-슬레이브 복제를 설정하려면:
1. 마스터 서버와 슬레이브 서버에 설치된 MySQL 버전이 동일한지 확인합니다.
복제는 연결 계정을 설정하는것이 좋습니다
. 해당 계정이 복제에만 사용되는 경우(권장) 다른 권한을 부여할 필요가 없습니다
. GRANT REPLICATION SLAVE ON *.*
-> TO 'replication'. @'%.yourdomain.com' IDENTIFIED BY 'slavepass';
3. FLUSH TABLES WITH READ LOCK 문을 실행하여 모든 테이블을 지우고 쓰기 문을 차단합니다.
mysql> FLUSH READ LOCK이 있는 테이블은
mysql 클라이언트 프로그램이 종료되는 것을 방지합니다. 터미널은 기본 서버 데이터 디렉터리의 스냅샷을 찍습니다.
shell> cd /usr/local/mysql/
shell> tar -cvf /tmp/mysql-snapshot.tar ./data
슬레이브 서버의 사용자 계정이 마스터 서버의 사용자 계정과 다르면 복사하지 않을 수도 있습니다. mysql 데이터베이스. 이 경우 해당 데이터베이스를 아카이브에서 제외해야 합니다. 또한 아카이브에 로그 파일이나 master.info 또는 Relay-log.info 파일을 포함할 필요가 없습니다.
FLUSH TABLES WITH READ LOCK으로 설정된 읽기 잠금이 유효한 경우(즉, mysql 클라이언트 프로그램이 종료되지 않는 경우) 메인 서버에서 현재 바이너리 로그 이름과 오프셋 값을 읽습니다.
mysql > SHOW MASTER STATUS
+--- --- ---------+----------+-------------+----------- --- ----+
| 위치 | Binlog_Ignore_DB
| --- -----+------+
| mysql-bin.003 | 테스트,mysql
| --- -------+----------+---------------+------------- --- --+
파일 열에는 로그 이름이 표시되고 위치에는 오프셋이 표시됩니다. 이 예에서 바이너리 로그 값은 오프셋 73의 mysql-bin.003입니다. 이 값을 기록하십시오. 이 값은 나중에 슬레이브 서버를 설정할 때 필요합니다. 이는 슬레이브가 마스터에서 새 업데이트를 시작해야 하는 복제 좌표를 나타냅니다.
마스터 서버가 실행 중일 때 --logs-bin이 활성화되지 않으면 SHOW MASTER STATUS에 의해 표시되는 로그 이름과 위치 값이 비어 있습니다. 이 경우, 향후 슬레이브 서버의 로그 파일과 위치를 지정할 때 사용해야 할 값은 빈 문자열('')과 4이다.
스냅샷을 촬영하고 로그 이름과 오프셋을 기록한 후 반환한다. 이전 중간 끝으로 이동하고 쓰기 활동을 다시 시작합니다.
mysql> UNLOCK TABLES
4. 마스터 서버 호스트에 있는 my.cnf 파일의 [mysqld] 섹션에 log-bin 옵션이 포함되어 있는지 확인합니다. 이 섹션에는 server-id=Master_id 옵션도 있어야 합니다. 여기서 master_id는 1에서 232–1 사이의 양의 정수 값이어야 합니다. 예:
[mysqld]
log-bin
server-id=1
해당 옵션이 제공되지 않은 경우 해당 옵션을 추가하고 서버를 다시 시작해야 합니다.
5. 슬레이브 서버에서 mysqld 서비스를 중지하고 my.cnf 파일에 다음 줄을 추가합니다.
[mysqld]
server-id=2
Slave_id 값은 Master_id 값과 동일하며 1에서 232 사이의 양의 정수여야 합니다. –1.가치. 또한, 슬레이브 서버의 ID는 마스터 서버의 ID와 달라야 합니다.
6. 백업 디렉터리에 데이터를 저장합니다. 이러한 파일 및 디렉터리에 대한 권한이 올바른지 확인하세요. MySQL 서버를 실행하는 사용자는 기본 서버에서와 마찬가지로 파일을 읽고 쓸 수 있어야 합니다.
Shell> chown -R mysql:mysql /usr/local/mysql/data
7. 슬레이브 서버를 시작합니다. 슬레이브 서버에서 다음 명령문을 실행하여 옵션 값을 시스템의 실제 값으로 바꾸십시오.
mysql> CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
- > MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
8.슬레이브
서버 스레드를 시작합니다:
mysql> START SLAVE;
스냅샷 이후 발생한 업데이트입니다.
9. 복제 오류가 발생하면 슬레이브 서버의 오류 로그(HOSTNAME.err)에도 오류 메시지가 나타납니다.
10. 서버에서 복사할 때 master.info 및 HOSTNAME-relay-log.info 파일이 해당 데이터 디렉터리에 있습니다. 슬레이브는 이 두 파일을 사용하여 마스터의 바이너리 로그가 얼마나 처리되었는지 추적합니다. 수행 중인 작업을 정확히 알고 그 중요성을 완전히 이해하지 않는 한 이러한 파일을 제거하거나 편집하지 마십시오. 그럼에도 불구하고 CHANGE MASTER TO 문을 사용하는 것이 더 좋습니다.