mysql 마스터-슬레이브 동기화란 무엇입니까?

MySQL 마스터-슬레이브 동기화는 백업을 의미합니다. 마스터 라이브러리(Master)는 자체 라이브러리의 쓰기를 슬레이브 라이브러리(Slave)에 동기화합니다. 마스터 라이브러리에서 예측할 수 없는 상황이 발생하면 전체 서버를 사용할 수 없습니다. 슬레이브 데이터베이스에도 데이터 복사본이 있으므로 데이터 손실을 유발하거나 줄이지 않고 데이터를 신속하게 복원할 수 있습니다.

mysql 마스터-슬레이브 동기화란 무엇입니까?

마스터 데이터베이스의 데이터가 변경되면 변경 사항이 실시간으로 슬레이브 데이터베이스에 동기화됩니다.

데이터는 애플리케이션의 중요한 부분입니다. 마스터-슬레이브 동기화는 목적상 약간의 백업 의미가 있습니다. 마스터 라이브러리(Master)는 자체 라이브러리에 있는 쓰기를 슬레이브 라이브러리(Slave)에 동시에 동기화합니다. 전체 서버를 사용할 수 없게 된 경우, 슬레이브 데이터베이스에도 데이터의 복사본이 있기 때문에 데이터 손실을 유발하거나 줄이지 않고 빠르게 데이터를 복원할 수 있습니다.

물론 이것은 첫 번째 레벨에 불과합니다. 마스터-슬레이브 라이브러리의 역할이 이에 국한된다면 개인적으로 데이터베이스를 두 개로 나눌 필요는 없다고 생각합니다. 콘텐츠를 스냅샷으로 다른 서버에 전송하거나, 작성된 콘텐츠를 작성할 때마다 실시간으로 다른 서버로 전송하면 자원 절약뿐만 아니라 재해 복구 및 백업 목적에도 도움이 된다면 좋지 않을까요?

물론 마스터-슬레이브 동기화의 역할은 이에 국한될 수 없습니다. 마스터-슬레이브 구조를 구성하면 일반적으로 슬레이브 노드가 백업 데이터베이스 역할만 하도록 두지 않습니다. 그에 따라 분리( MyCat이나 다른 미들웨어를 사용할 수 있고, 직접 배울 수도 있습니다. 이에 대해서는 다음 MyCat 블로그에서 다루겠습니다. 조금 길 수 있으므로 따로 작성하겠습니다.)

실제 환경에서는 데이터베이스에 대한 읽기 작업 수가 데이터베이스에 대한 쓰기 작업 수보다 훨씬 많기 때문에 마스터가 쓰기 기능만 제공하도록 하고 모든 읽기 작업을 슬레이브 데이터베이스로 옮길 수 있습니다. . 우리가 흔히 말하는 읽기와 쓰기를 분리하는

이것은 마스터의 부담을 줄일 수 있을 뿐만 아니라 재해 복구 백업도 제공하여 일석이조를 제공합니다.

마스터-슬레이브 동기화의 이점은 무엇인가요?

• 데이터베이스의 로드 용량을 수평으로 확장합니다.

• 내결함성, 고가용성. 장애 조치/고가용성

• 데이터 백업.

MySQL 마스터-슬레이브 동기화의 원리

마스터-슬레이브 동기화의 개념에 대해 이야기한 후 마스터-슬레이브 동기화의 원리에 대해 이야기해 보겠습니다. 사실 원리도 매우 간단하며, 그렇지 않습니다. Redis 클러스터만큼 개념이 많습니다.

실제로 MySQL에서 마스터-슬레이브를 구성한 후 마스터 노드에서 쓰기 작업을 수행하는 한 이 작업은 슬레이브가 실행될 때 MySQL의 바이너리 로그(bin-log) 로그에 저장됩니다. 이 때 마스터 머신은 슬레이브에 대한 binlog 덤프 스레드를 엽니다. 마스터의 binlog가 변경되면 마스터의 덤프 스레드는 슬레이브에 알리고 해당 binlog 콘텐츠를 슬레이브에 보냅니다. 마스터-슬레이브 동기화가 활성화되면 슬레이브 노드는 I/O 스레드와 SQL 스레드라는 두 개의 스레드를 생성합니다. 이는 후속 구성에서 우리 눈으로 볼 수 있습니다.

• I/0 스레드: 이 스레드는 마스터 시스템의 binlog가 슬레이브로 전송되면 IO 스레드가 로컬 릴레이 로그(릴레이 로그)에 로그 내용을 기록합니다. .

• SQL 스레드: 이 스레드는 릴레이 로그의 내용을 읽고 릴레이 로그의 내용을 기반으로 슬레이브 데이터베이스에서 해당 작업을 수행합니다.

• 가능한 문제: 쓰기 요청이 많은 경우 슬레이브 데이터와 마스터 데이터가 일치하지 않을 수 있습니다. 이는 로그 전송 프로세스가 짧게 지연되거나 쓰기 명령이 많기 때문입니다. 시스템 속도 불일치로 인해 발생합니다.

이것은 대략 MySQL 마스터-슬레이브 동기화의 원리입니다. 여기서 실제로 중요한 역할을 하는 것은 실제로 이 두 로그 파일인 binlog와 릴레이 로그입니다.

MySQL 마스터-슬레이브 동기화 수동 구축

환경 준비

이번에 마스터-슬레이브 동기화 설정 환경은 CentOS 7, MySQL 8.0.18(바이너리 패키지를 사용하여 설치)입니다.

시나리오 소개

이번에는 하나의 마스터와 두 개의 슬레이브를 포함하여 MySQL 마스터-슬레이브 동기화를 설정하겠습니다.

Master:IP :192.168.43.201 Port:3306
Slave1:IP:192.168.43.202 Port:3306
Slave2:IP:192.168.43.203 Port:3306

빌드 시작

구성 파일 수정

MySQL을 설치한 후 /etc/ 디렉터리에 my.cnf 파일이 있을 것입니다. 파일을 열고 다음 내용을 추가합니다(백업하는 것을 잊지 마세요). 수정 전):

x

#该配置为Master的配置
server-id=201 #Server id 每台MySQL的必须不同
log-bin=/var/lib/mysql/mysql-bin.log #代表开启binlog日志
expire_logs_days=10 #日志过期时间
max_binlog_size=200M #日志最大容量
binlog_ignore_db=mysql #忽略mysql库，表示不同步此库

y

#该配置为Slave的配置,第二台Slave也是这么配置，不过要修改一下server-id
server-id=202
expire_logs_days=10 #日志的缓存时间
max_binlog_size=200M #日志的最大大小
replicate_ignore_db=mysql #忽略同步的数据库

슬레이브 사용자 추가

마스터 노드의 클라이언트를 엽니다. mysql -u root -p 비밀번호

사용자 생성 사용자 생성 'Slave'@'%' '123456'으로 식별;

create user 'Slave'@'%' identified by '123456';

给新创建的用户赋权：grant replication slave on '*.*' to 'Slave'@'%';새로 생성된 사용자 부여: '*.*'의 복제 슬레이브를 'Slave'@'%'에 부여;

마스터 노드 상태 보기

위 작업에 문제가 없으면 클라이언트에 show master status를 입력하여 마스터의 binlog 로그를 봅니다.

配置两个Slave节点

打开两个Slave节点客户端，在我们的另外两个Slave节点中输入如下命令：

change master to master_user='Slave',master_password='123456',master_host='192.168.43.201',master_log_file='mysql-bin.000005',master_log_pos=155,get_master_public_key=1;
#注意，这里的master_log_file，就是binlog的文件名，输入上图中的mysql-bin.000005,每个人的都可能不一样。
#注意，这里的master_log_pos是binlog偏移量，输入上图中的155，每个人的都可能不一样。

配置完成后，输入start slave;开启从节点，然后输入show slave status\G;查看从节点状态

可以看到，在两台Slave的状态中，我们能亲眼看到IO线程和SQL线程的运行状态，这两个线程必须都是yes，才算配置搭建完成。

搭建完成

通过上述步骤，就完成了MySQL主从同步的搭建，相对Redis而言MySQL配置相当简单。下面我们可以进行测试。

先看看三个MySQL的数据库状态：SHOW DATABASES;

可以看到现在数据库都是初始默认状态，没有任何额外的库。

在Master节点中创建一个数据库，库名可以自己设置。

CREATE DATABASE testcluster;

<img class="has lazy" src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/024/fefa55750f9a4ddaec29168c6cc022e9-4.png?x-oss-process=image/resize,p_40" alt="">

可以看到，在Slave中也出现了Master中创建的数据库，说明我们的配置没有问题，主从搭建成功。这里就不再创建表了，大家可以自己试试，创建表再往表中插入数据，也是没有任何问题的。

注意事项

如果出现IO线程一直在Connecting状态，可以看看是不是三台机器无法相互连接，如果可以相互连接，那么有可能是Slave账号密码写错了，重新关闭Slave然后输入上面的配置命令再打开Slave即可。

如果出现SQL线程为NO状态，那么有可能是从数据库和主数据库的数据不一致造成的，或者事务回滚，如果是后者，先关闭Slave，然后先查看master的binlog和position，然后输入配置命令，再输入set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;，再重新start slave;即可，如通过是前者，那么就排查一下是不是存在哪张表没有被同步，是否存在主库存在而从库不存在的表，自己同步一下再重新配置一遍即可。

结语

在写这篇文章之前自己也被一些计算机领域的“名词”吓到过，相信有不少同学都有一样的体会，碰上某些高大上的名词总是先被吓到，例如像“分布式”、“集群”等等等等，甚至在没接触过nginx之前，连”负载均衡“、”反向代理“这样的词都让人觉得，这么高达上的词，肯定很难吧，但其实自己了解了nginx、ribbon等之后才发现，其实也就那么回事吧，没有想象中的那么难。

所以写这篇文章的初衷是想让大家对集群化或者分布式或者其他的一些技术或者解决方案不要有一种望而却步的感觉（感觉计算机领域的词都有这么一种特点，词汇高大上，但是其实思想是比较好理解的），其实自己手动配置出一个简单的集群并没有那么难。

如果学会docker之后再来配置就更加简单了，但是更希望不要只局限于会配置，配置出来的东西只能说你会配置了，但是在这层配置底下是前人做了相当多的工作，才能使我们通过简单配置就能实现一些功能，应该要深入底层，了解配置下面的工作原理，这个才是最重要的，也是体现一个程序员水平的地方。

推荐教程：mysql视频教程

위 내용은 mysql 마스터-슬레이브 동기화란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!