I. 서론
MySQL이 복제 방식으로 제공, 혜택은 다음과 같습니다 :
데이터 백업.
로드 밸런싱.
분산 데이터입니다.
개념 :
호스트 (마스터) : 데이터베이스가 복제됩니다.
슬레이브 (노예) : 데이터베이스 호스트 데이터를 복사합니다.
복사 단계 :
(1) 변화의 마스터 레코드 세부 사항은 이진 (바이너리 로그)에 로그인 ..
(2). 마스터는 슬레이브 동기화 메시지를 송신한다.
(3). 슬레이브 메시지 로컬 바이너리 로그 로그 (릴레이 로그)에 릴레이의 마스터 카피를 수신 한 후.
(4). 슬레이브는 데이터베이스에서 데이터를 변경 중계 로그 메시지를 재생.
이 과정을 설명하기 위해 고전적인 그림의 조각을 장소 : 
II. 구현 복제
다음 단계를 구현 복사합니다 :
1. 주요 MySQL 데이터베이스 서버 ID와 바이너리 로그
MySQL의 설정 파일은 일반적으로 /etc/my.cnf에 저장된다
# 在[mysqld]下面添加配置选项
[mysqld]
server-id=1
log-bin=mysql-bin.log서버 ID가 데이터베이스에 고유 식별자 전체 데이터베이스 클러스터이며, 고유해야합니다.
MySQL의를 다시 시작합니다.
注：如果MySQL配置文件中已经配置过此文件，则可以跳过此步。
2. 새 계정을 복사
데이터베이스에서 데이터를 복사하고 복사 할 수있는 권한을 부여하는 데 사용되는 새로운 중앙 도서관 계정 내부의 중앙 도서관에서.
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO user_name@'host' IDENTIFIED BY 'password';3. 기본 MySQL 데이터베이스 서버 ID를 설정
그리고 주목해야 할 두 지점이 두 번째 단계로 구성 :
- 다른 라이브러리에서 기본 라이브러리로 라이브러리에서없는 경우에, 당신은 바이너리 로그를 구성 할 필요가 없습니다.
- 많은 경우에 당신은 중앙 도서관 (특히 MySQL의 구성 정보 저장소)를 복사 할 전체 데이터베이스를 복사 할 필요가 없습니다. 당신은 복제 된 데이터베이스를 지정 replicate_do_db를 구성 할 수 있습니다
주요 라이브러리에서 4. 라이브러리 초기화 데이터
데이터의 양이 크지 않은 경우,이 도구는 다음 저장소로 가져 mysqldump를 마스터 데이터 저장소를 내보낼 수 있습니다.
mysqldump --single-transaction --triggers --master-data databasename > data.sql상황이 Xtrabackup 데이터베이스를 사용하여 내보낼 많은 양의 데이터에서 할 필요가있는 경우, 여기에 대해서는 설명하지 않습니다.
학생들이 왜 초기화하기 위해 바이너리 로그를 사용하지 질문이있을 수 있습니다?
- 우리는 상대적으로 오랜 기간 주요 라이브러리를 실행하고 바이너리 로그에 따라 데이터베이스에서 데이터를 복사하기 위해 사용하기에 적합하지 않은 경우, 더 많은 시간이 소요 및 성능 될 라이브러리에서 초기화하는 바이너리 로그를 사용합니다.
- 더 자주, 주요 라이브러리의 바이너리 로그 구성 항목이 열려 있지 때문에 작업 전에 어떤 바이너리 로그가 없습니다.
5. 복사 오픈
라이브러리에서 다음 명령을 실행
mysql> CHANGE MASTER TO MASTER_HOST='host',
-> MASTER_USER='user',
-> MASTER_PASSWORD='password', -> MASTER_LOG_FILE='mysql-bin.000001', -> MASTER_LOG_POS=0;마지막 두 명령 참고 : MASTER_LOG_FILE과 MASTER_LOG_POS, 라이브러리에서 이진 파일의 시작을 나타내는 거기에서 오프셋에서 읽기,이 두 가지 매개 변수 안에 우리의 수입 SQL에서 찾을 수 있습니다.
열기 사본
start slave;이 시간은 그 결과에 라이브러리에서 조회 할 수 있습니다 주요 라이브러리에 데이터 또는 새로운 데이터를 업데이트, 복사를 완료합니다.
주요 도서관에 당신은 또한 복제 스레드의 상태를 확인할 수 있습니다.
III. 로그 형식을 복사
MySQL의 복제 로그 형식, 세 가지 주요 방법이 다른 인벤토리 데이터에 따라 거기는 다음 세 가지 넣어 :
| 복제 | 특징 | 이점 | 결점 |
|---|---|---|---|
| 열 | 각 행에 대한 상기 정보 데이터의 기록의 변형에 기초하여 복사 행 형식. 당신은 SQL 데이터 2w 라인을 수정하는 경우, 그것은 형식 라인 2w를 기록합니다 | 강력한 데이터 일관성을 확인하고 기록 실행 결과이기 때문에, 데이터베이스에서 실행이 빨라집니다 복원 | 로그 레코드의 많은 수는 마스터와 슬레이브 사이의 전송 시간이 더 필요합니다. |
| 성명서 | 기록 SQL 레코드 변경보다는 변화의 행입니다 복제 형식으로 세그먼트를, 로그 기반. | 로깅 최소량. | 데이터가 다시 SQL 복원 로그에 따라 수행 될 필요가있을 때, 출력 결정적 결과의 일부 기능은 구현 시간이 비교적 느리기 라이브러리 주요 라이브러리 같은 UUID와 같은 라이브러리로부터 다시 문제가 될 가능성이있다. |
| 혼합 된 | 그런데 로그 MySQL을 자체적으로 결정되는 경우에 사용하는 바와 같이, 상기 두 개의 로그 형식의 로그 기록을 혼합. | 당신은 위의 두 로그 형식의 장점과 단점을 균형을 수 있습니다. |
기본 형식 전에 mysql5.7 문.
모드 설정, 당신은 (선호) 구성 파일에 설정할 수 있습니다 :
binlog_format=ROW또는 일시적으로 전역 변수 (현재 연결은 유효한 MySQL의 것입니다) :
查看日志格式
mysql > show variables like 'binlog_format';
设置日志格式
mysql > set binlog_format='row';由于两个主从服务器一般都会放在同一个机房里面，两者之间同步的速度会会比较快，为保证强一致性，应该首选行的日志格式记录（row），保证传输素速度可以选择混合方式（mixed）。
而行的日志格式有下面三种记录方式：
| 记录方式 | 特点 |
|---|---|
| minimal | 只记录被修改列的数据 |
| full | 记录被修改的行的全部列的数据 |
| noblob | 特点同上，只是如果没有修改blob和text类型的列的情况下，不会记录这些列的数据（也就是大数据列） |
mysql默认是full，最好修改成minimal。
binlog_row_image=minimal四. 主从复制延迟
由于主库和从库之间不在同一个主机上，数据同步之间不可以避免地具有延迟，解决的方法有添加缓存，业务层的跳转等待，如果非得从数据库层面去减缓延迟问题，可以从复制时候的三大步骤（主库产生日志，主从传输日志，从库还原日志内容）入手：
1.主库写入到日志的速度
控制主库的事务大小，分割大事务为多个小事务。
如插入20w的数据，改成插入多次5000行（可以利用分页的思路）
2.二进制日志在主从之间传输时间 主从之间尽量在同一个机房或地域。
日志格式改用MIXED，且设置行的日志格式未minimal，原理详见上面的日志格式介绍。
3.减少从库还原日志的时间
在MySQL5.7版本后可以利用逻辑时钟方式分配SQL多线程。
设置逻辑时钟：slave_parallel_type=‘logical_clock’;
设置复制线程个数：slave_parallel_workers=4;
五. 需要注意的地方
- 重启MySQL最好切换未MySQL用户再进行操作，不然文件启动后会有权限问题。
- 데이터베이스 라이브러리에서 복사해야하는 경우, 데이터베이스를 다시 시작할 필요가 없습니다 있도록 MySQL은 사업을 중단, 로그 - 빈 옵션 설정 구성 후 좋은 환경을 구축합니다.
- 당신은 MySQL의 주요 도서관을 해당 방화벽 포트를 열어야합니다.
- 인해 오류가 통신 다시 연결 발생할 경우 차 라이브러리 조작 데이터를 변경하지 않으면되므로 오히려 폴링보다는, 전송되는 정보의 기본 라이브러리 모니터링 기본 라이브러리 데이터베이스 동기화의 방법으로, 동기화 된 데이터는 따라서, 라이브러리 아니다 널 데이터를 삽입하는 트랜잭션에 의해 동기화 될 수있다.