기사 디렉토리

에서, MySQL의 마스터 사본

1. 왜 마스터 - 슬레이브 복제를합니까?
2, MySQL의 마스터 - 슬레이브 복제 원리
3, 비동기 복제

둘째, 비동기 복제의 위치에 따라
셋째, 비동기 복제를 기반으로 GTID

1, DTID 의미
2, 장점
3, GTID 작품
마스터에 기초하여 (4)는 복사 GTID

에서, MySQL의 마스터 사본

1. 왜 마스터 - 슬레이브 복제를합니까?

비즈니스 복잡한 시스템, 이러한 시나리오는 잠금 테이블의 SQL 문에 대한 필요가 일시적으로 서비스의 결과는 그래서 중앙 도서관은 도서관에서 쓰기에 대한 책임이 있다고는, 마스터 - 슬레이브 복제를 사용하여, 사업의 작동에 영향을 미칠 후, 읽을 수 없습니다가,가 읽기에 대한 책임, 있도록 중앙 도서관 현장은 사업의 정상적인 작동을 보장 할 수 라이브러리에서 읽어 잠금 테이블 등장 경우에도 마찬가지입니다. 확장 아키텍처. 비즈니스의 볼륨을 증가, I / O를 액세스 빈도는 독립 할 수없는 대회, 다음, 저장, 여러 도서관을 디스크 I / O 액세스의 빈도를 줄이고, 단일 시스템 I / O 성능을 향상 너무 높습니다.

2, MySQL의 마스터 - 슬레이브 복제 원리

마스터 서버의 연결, 그것은 로그의 마스터 서버에서 읽을 마지막으로 성공한 업데이트의 위치를 알립니다. 그 이후, 서버는 일어나는 모든 업데이트를 수신 한 다음 새 업데이트의 통지를 메인 서버와 대기를 차단.

그림 삽입 설명 여기

주님은 중앙 도서관의 기지에서 복사되는 모든 데이터베이스 레코드의 바이너리 로그의 변경 (바이너리 로그, 이벤트가 바이너리 로그 파일을 저장하기 위해 마스터 저장소를 갱신)를 기록합니다. 바이너리 로그는 모든 만료 시간 내에 데이터베이스 구성에 저장된 파일의 데이터베이스 구조 나 내용을 수정합니다. 만료 시간이 10D 인 경우 최근 데이터베이스 10D는 변경 로그입니다.
복제 과정에서 MySQL의 마스터 복제 마스터는 라이브러리에서 라이브러리에 업데이트 이벤트를 전송하는 데이터베이스에서 업데이트 된 기록을 읽고, 업데이트 기록을 수행, 비동기, 등이 기본 데이터베이스와 라이브러리 일치의 콘텐츠.

에서 주요 라이브러리 , 한 이벤트가 발생하는 업데이트가있는 한, 그것은 순차적 라이브러리 마스터 라이브러리와의 연결이 마스터 카피 동작 쿨라 데이터 소스로부터 인계하는 후 바이너리 로그에 기록한다.
바이너리 로그 출력 스레드 메인 라이브러리 라이브러리로부터의 연결이있을 때마다 주기억 라이브러리는 스레드를 생성하고 라이브러리의 내용 바이너리 로그로 전송한다. 출력 스레드가 잠금 상태가됩니다 바이너리 로그 각 이벤트의 경우, SQL 데이터베이스에 확인할 수 있습니다. 이벤트가 스레드를 읽고 완료되면, 잠금이 이벤트가 잠금이 출시 될 경우에도 시간에서 전체로 라이브러리를 전송, 해제됩니다.
에 라이브러리 복사가 시작할 때, 두 개의 스레드가 라이브러리에서 처리가 생성됩니다 :

라이브러리 I / O 스레드에서 후에 시작 라이브러리에서 START SLAVE 문은 도서관, 도서관에서 I / O 스레드를 시작하고 메인 쓰레드 라이브러리에 전송 바이너리 로그 내부의 마스터 데이터베이스 레코드를 업데이트 요청에 연결되어있을 때.
업데이트는 중앙 도서관 라이브러리 I / O 출력 바이너리 로그 스레드에서 읽고 스레드가 릴레이 로그 파일을 포함하여 파일의 로컬 복사본에 대한 업데이트를 보냅니다.

SQL 스레드 라이브러리에서 I / O 쓰레드가 기록이 스레드 릴레이 로그 (릴레이 로그)를 읽고 업데이트 이벤트를 수행하는 라이브러리에서, 라이브러리에서 SQL 스레드를 시작합니다.

알고는 연결의 마스터 복사본의 각각에 대해 세 가지 스레드가 있습니다. 각각의 모든 라이브러리 / O 스레드와 SQL 스레드 메인 라이브러리에서 라이브러리에 자신의 I를 가지고에서 주요 라이브러리에 연결, 라이브러리에서 바이너리 로그 출력 스레드를 만들 수보다 더있다. 복사가 수행 그래서, 두 개의 스레드 라이브러리에서 시작하여, 읽기 및 쓰기 라이브러리에서 분리 하였다. 심지어 느리게 실행 스레드의 실행을 담당하는 경우 따라서, 업데이트 문 스레드를 읽고에 대한 책임이 느린되지 않습니다. 이 경우 여기에서 시작했을 때 예를 들어, 일정 기간은 I / O 스레드가 신속하게 중앙 도서관에서 모든 바이너리 로그의 내용을 읽을 수 있습니다, 더 천천히 SQL 쓰레드가 실행에도 불구하고, 라이브러리에서 실행되지 않았다. 그 결과, 문 앞에 모든 읽기는 SQL 스레드의 라이브러리에서 실행되는 경우에도 실행을 중지하고, I / O 쓰레드는 완전히 모든 콘텐츠를 읽을 적어도 또한, 안전하게 로컬 릴레이 로그에서 라이브러리에 백업 도서관의 시작까지의 시간에 문을 실행할 준비가.

3, 비동기 복제

메인 즉시 클라이언트에 결과를 반환합니다 클라이언트에 의해 제출 된 트랜잭션 실행 완료 후 도서관,이 라이브러리에서 치료를 받았는지 상관하지 않는다, 그래서 문제, 주요 라이브러리 즉, 기본 MySQL의 복제가 비동기입니다있을 것 당신이 밖으로 충돌하는 경우이 시간에, 주력을 향상 경우, 제출 된 주요 라이브러리에 현재 트랜잭션이 완료되지 않은 새 기본 데이터베이스의 데이터가 발생할 수, 라이브러리에서되는 양도 할 수 없습니다.

둘째, 비동기 복제의 위치에 따라

실험 환경

실험 환경

IP 호스트 이름	서비스
가상 컴퓨터 서버 1 172.25.7.1	마스터 노드 데이터베이스
가상 머신 서버 2 172.25.7.2	슬레이브 노드 데이터베이스
물리적 기계 172.25.7.250	최종 테스트

1,서버 1과 서버 2에mysql을 rpm 패키지 추출 다운로드 :
타르 XF는 MySQL의-5.7.24-1.el7.x86_64.rpm-bundle.tar
그림 삽입 설명 여기

2, 패키지 설치가 필요합니다

yum install -y mysql-community-client-5.7.24-1.el7.x86_64.rpm mysql-community-common-5.7.24-1.el7.x86_64.rpm mysql-community-libs-5.7.24-1.el7.x86_64.rpm mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm mysql-community-server-5.7.24-1.el7.x86_64.rpm

그림 삽입 설명 여기

server2上同样的操作： 그림 삽입 설명 여기

3、修改配置文件，开始配置主节点（server1）数据库 vim /etc/my.cnf

在文件末尾写：
log-bin=mysql-bin
server-id=1(每个节点的序号是唯一的)

그림 삽입 설명 여기

4、master节点（server1 ）的数据库初始化

1）开启服务之后会生成一个临时密码，使用临时密码进行数据库安全初始化，复制密码：cat /var/log/mysqld.log | grep password
2）mysql -uroot -p 粘贴密码，登录成功
3）show databases;发现必须进行初始化
그림 삽입 설명 여기

4）安全初始化：mysql_secure_installation

安全初始化登陆的时候使用的是临时密码，接下来要自己设置数据库的密码，这个密码必须有特殊字符，英文字母的大小写还有数字

그림 삽입 설명 여기

5）使用自己设置的密码登录数据库：mysql -uroot -pWestos123==

그림 삽입 설명 여기

5、slave节点（server2 ）的数据库初始化
1）vim /etc/my.cnf

그림 삽입 설명 여기

그림 삽입 설명 여기
2）复制密码：cat /var/log/mysqld.log | grep password
3）安全初始化：mysql_secure_installation

그림 삽입 설명 여기
4）使用自己设置的密码登录slave数据库：mysql -uroot -pWestos123==

그림 삽입 설명 여기
6、在 master 上，创建并授权用来做复制的用户

在Master的数据库中建立一个备份帐户：每个slave使用标准的MySQL用户名和密码连接master。进行复制操作的用户会授予REPLICATION SLAVE权限。用户名的密码都会存储在文本文件master.info中

mysql> grant replication slave on *.* to repl@'172.25.7.%' identified by 'Westos==123';
		## 创建用户，可以使用此用户远程登录数据库；授权为可以复制master节点数据的slave节点
mysql> show plugins;	
		##查看插件，因为有密码插件，所以密码必须设置为复杂的 
mysql> show master status;	
		##查看master状态

参数	解释
REPLICATION	表示复制的权限
* .*	表示对所有库的所有表都授权
repl	用户名
‘172.25.7.%’	授权172.25.7网段的所有数据库节点都可以同步（复制）

그림 삽입 설명 여기

7、在 slave（server2）上配置master信息

mysql> change master to master_host='172.25.7.1'，  
		##在这个slave节点上面设置管理它的master节点主机信息
	->master_user='repl'，
		##用户
	->master_password='Westos==123',
		##密码
	->master_log_file='mysql-bin.000002', 
		##基于position的主从复制的重要信息
	->master_log_pos=861;
 		##
mysql> start slave; ##开启本节点的slave
mysql> show slave status\G	##查看主从复制状态 
##这两个参数是Yes，表示成功 。Slave_IO_Running:  Yes   Slave_SQL_Running: Yes

对于slave节点来说，io线程和sql线程是最重要的两个线程。只有当io线程和sql线程都开启的时候，slave节点才可以正常复制master节点的数据

그림 삽입 설명 여기

8、测试主从同步是否生效

注意：写操作只能在master节点上做，因为master节点不会去同步slave节点的内容
在master创建新数据

mysql> create database ranran;	       ##在server2上发现也能看到westos库
mysql> use ranran
mysql> create table usertb (
    -> username varchar(10) not null,
    -> password varchar(15) not null);	 ##建表

mysql> desc usertb;	                     ##查看表信息
mysql> insert into usertb values ('user1','123');	##插入数据
mysql> select * from usertb;	##查看

그림 삽입 설명 여기

在slave查看select * from ranran.usertb;
그림 삽입 설명 여기

三、基于GTID的异步复制

1、 DTID的含义

Global Transaction Identifier，全局事务标识
一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
基于gtid的主从复制原理：每个mysql数据库上都有一个唯一uuid，每个事务生成一个id。gtid由上面两者组合： uuid+事务id

2、优势

更简单的搭建主从复制。
比传统的复制更加安全。在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。
GTID是连续的没有空洞的，保证数据的一致性，零丢失
主从提升更加简单容易。从服务器连接到主服务器之后，把自己执行过的GTID(Executed_Gtid_Set)<SQL线程> 、获取到的GTID(Retrieved_Gtid_Set）<IO线程>发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主，先change到同步最成功的那台从服务器，等把GTID全部补全了，就可以把它提升为主了

3、GTID工作原理

当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
如果有记录，说明该GTID的事务已经执行，slave会忽略。
如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

4、基于GTID的主从复制

此实验是基于position的主从复制的基础上做的

1、在server1上，配置主节点
1）修改配置文件加入开启gtid的信息，vim /etc/my.cnf

gtid_mode=ON
enforce-gtid-consistency=true

그림 삽입 설명 여기
此时登录数据库： mysql -uroot -pWestos123==

mysql>use mysql；
mysql>select * from gtid_executed;

发现gtid_executed是空的，

2）在/var/lib/mysql路径下，mysqlbinlog mysql-bin.000002 可以看到之前的全部操作。

그림 삽입 설명 여기
3）在/var/lib/mysql路径下，cat auto.cnf 查看此节点的uuid

4）重启数据库：systemctl restart mysqld

2、在server2上，配置slave
1）vim /etc/my.cnf，加入：开启gtid的信息
그림 삽입 설명 여기
2）systemctl restart mysqld
3）在/var/lib/mysql路径下，cat relay-log.info

4）此时登录数据库： mysql -uroot -pWestos123==

mysql> stop slave;				##先停止复制
mysql> CHANGE MASTER TO			##修改master信息
    -> MASTER_HOST = '172.25.7.1',
    -> MASTER_USER = 'repl',
    -> MASTER_PASSWORD = 'Westos==123',
    -> MASTER_AUTO_POSITION = 1;	##启用gtid，它是自动的
mysql> start slave;
mysql> show slave status\G			##查看状态，可以看到下面两个参数是空的
 		Retrieved_Gtid_Set: 
        Executed_Gtid_Set:

그림 삽입 설명 여기

3、在server1上插入数据

mysql>use ranran
mysql> insert into usertb values ('user2','123');
mysql> insert into usertb values ('user3','123');

그림 삽입 설명 여기

4、在server2上面查看状态和同步的数据

发现这两个参数 Retrieved_Gtid_Set: /Executed_Gtid_Set: 变了，从1位置开始复制的

그림 삽입 설명 여기
再查看gtid模式复制的起始和结束位置

此时查看表，即可看到插入内容。

草莓啾啾啾

发布了102 篇原创文章 · 获赞 21 · 访问量 5331

개인 편지 우려

MySQL의 데이터베이스 클러스터 전투 --- 복제의 MySQL의 마스터 - 슬레이브 비동기 모드 (위치에 따라, GTID 기준)

기사 디렉토리

에서, MySQL의 마스터 사본

1. 왜 마스터 - 슬레이브 복제를합니까?

2, MySQL의 마스터 - 슬레이브 복제 원리

3, 비동기 복제

둘째, 비동기 복제의 위치에 따라

三、基于GTID的异步复制

1、 DTID的含义

2、优势

3、GTID工作原理

4、基于GTID的主从复制

추천