이 기사는 마스터-슬레이브 복제 아키텍처, 캐스케이드 복제 아키텍처, 다중 마스터-슬레이브 복제 아키텍처 등을 포함하여 복제 아키텍처와 관련된 문제를 주로 소개하는 mysql에 대한 관련 지식을 제공합니다. 모두에게 도움이 되기를 바랍니다.
추천 학습: mysql 비디오 튜토리얼
실제 애플리케이션 시나리오에서 MySQL 복제의 90% 이상이 하나의 마스터가 하나 이상의 슬레이브에 복제되는 아키텍처 패턴입니다. .
메인 라이브러리의 읽기 요청 부담이 매우 높은 시나리오에서는 하나의 마스터 다중 슬레이브 복제 아키텍처를 구성하여 읽기 및 쓰기 분리를 달성하고 읽기 요청이 없는 대량의 읽기 요청을 분산할 수 있습니다. 로드 밸런싱을 통해 특히 높은 실시간 요구 사항을 충족합니다. 아래 그림과 같이 여러 슬레이브 라이브러리(실시간 요구 사항이 높은 읽기 요청을 마스터 라이브러리에서 읽을 수 있음)에서 마스터 라이브러리에 대한 읽기 부담을 줄입니다.
단점:
마스터가 필요하기 때문입니다. 정기적인 유지 관리를 위해 종료된 경우 슬레이브를 마스터로 변환해야 합니다. 어느 것이 문제입니까?를 선택하십시오.
슬레이브가 마스터가 되면 현재 마스터와 이전 마스터의 데이터가 일치하지 않으며, 이전 마스터가 현재 마스터 노드의 binlog 파일과 POS 위치를 저장하지 않았습니다.
다중 마스터 복제 아키텍처는 단일 마스터 다중 슬레이브 복제 아키텍처에서 마스터의 단일 실패 지점 문제를 해결합니다.
킵얼라이브와 같은 타사 도구를 사용하면 IP 드리프트를 쉽게 달성할 수 있으므로 마스터 가동 중지 시간 및 유지 관리가 쓰기 작업에 영향을 미치지 않습니다.
하나의 마스터와 많은 슬레이브가 있는 경우 각 슬레이브 라이브러리가 독립적인 BINLOG를 가지게 되므로 슬레이브 라이브러리의 증가에 따라 메인 라이브러리의 I/O 압력과 네트워크 압력이 증가합니다. 덤프 스레드는 이벤트를 보내는 데 사용되며 캐스케이드 복제 아키텍처는 마스터-다중 슬레이브 시나리오에서 기본 라이브러리에 대한 추가 I/O 및 네트워크 압력을 해결합니다.
아래 사진과 같습니다.
1-마스터-다중-슬레이브 아키텍처와 비교하여 계단식 복제는 마스터 데이터베이스의 데이터를 소수의 슬레이브 데이터베이스에만 복사하고 다른 슬레이브 데이터베이스는 이 소수의 슬레이브 데이터베이스에서 데이터를 복사하므로 마스터 데이터베이스 마스터의 작업 부하를 완화합니다.
물론 단점도 있습니다. MySQL의 기존 복제는 비동기식입니다. 계단식 복제 시나리오에서는 마스터 데이터베이스의 데이터가 다른 슬레이브 데이터베이스에 도달하기 전에 두 번 복제되어야 합니다. 단일 마스터 및 다중 슬레이브 복제 시나리오는 훨씬 더 큽니다.
보조 슬레이브에서 테이블 엔진을 BLACKHOLE로 선택하면 캐스케이드 복제의 대기 시간을 줄일 수 있습니다. 이름에서 알 수 있듯이 BLACKHOLE 엔진은 "블랙홀" 엔진입니다. BLACKHOLE 테이블에 기록된 데이터는 항상 INSERT, UPDATE 및 DELETE 작업만 기록하는 빈 테이블입니다. BINLOG에 있습니다.
다음은 BLACKHOLE 엔진을 보여줍니다.
mysql> CREATE TABLE `user` (
-> `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
-> `name` varchar(255) NOT NULL DEFAULT '',
-> `age` tinyint unsigned NOT NULL DEFAULT 0
-> )ENGINE=BLACKHOLE charset=utf8mb4;Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO `user` (`name`,`age`) values("itbsl", "26");Query OK, 1 row affected (0.00 sec)mysql> select * from user;Empty set (0.00 sec)BLACKHOLE의 스토리지 엔진을 사용하면 사용자 테이블에 데이터가 없는 것을 볼 수 있습니다.
다중 마스터 및 캐스케이드 복제 아키텍처를 결합하여 단일 포인트 마스터 문제를 해결하고 슬레이브 캐스케이드 지연 문제를 해결합니다.
호스트 계획:
구성 파일 my.cnf :
$ cat /home/mysql/docker-data/3315/conf/my.cnf [mysqld] character_set_server=utf8 init_connect='SET NAMES utf8' symbolic-links=0 lower_case_table_names=1 server-id=1403314 log-bin=mysql-bin binlog-format=ROW auto_increment_increment=2 # 几个主库，这里就配几 auto_increment_offset=1 # 每个主库的偏移量需要不一致 gtid_mode=ON enforce-gtid-consistency=true binlog-do-db=order # 要同步的数据库
Docker 시작:
$ docker run --name mysql3314 -p 3314:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3314/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3314/data/:/var/lib/mysql -v /home/mysql/docker-data/3314/logs/:/var/log/mysql -d mysql:5.7
복제를 위한 사용자 추가 및 승인:
mysql> GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456'; Query OK, 0 rows affected, 1 warning (0.01 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.01 sec)
master1 동기화 시작(여기서 사용자는 master2에서 옴):
mysql> change master to master_host='172.23.252.98',master_port=3315,master_user='repluser',master_password='123456',master_auto_position=1; Query OK, 0 rows affected, 2 warnings (0.03 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec)
master2 구성은 master1과 유사합니다.
가장 큰 차이점은 my.cnf에 일관성이 없어야 하는 속성이 있다는 것입니다.
auto_increment_offset=2 # 每个主库的偏移量需要不一致
테스트:
master2에 테이블 생성 및 데이터 추가:
mysql> create table t_order(id int primary key auto_increment, name varchar(20));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t_order(name) values("A");
Query OK, 1 row affected (0.01 sec)
mysql> insert into t_order(name) values("B");
Query OK, 1 row affected (0.00 sec)
mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
| 2 | A |
| 4 | B |
+----+------+
2 rows in set (0.00 sec)에서 id의 단계 크기를 확인할 수 있습니다. master2는 2이고, 2부터 증가합니다.
그런 다음 master1의 데이터를 쿼리하고 다음을 추가합니다.
mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
| 2 | A |
| 4 | B |
+----+------+
2 rows in set (0.00 sec)
mysql> insert into t_order(name) values("E");
Query OK, 1 row affected (0.00 sec)
mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
| 2 | A |
| 4 | B |
| 5 | E |
+----+------+
3 rows in set (0.00 sec)master1의 ID 단계 크기가 2이고 1부터 증가하기 시작합니다. 그런 다음 master2의 데이터를 쿼리하면 다음을 사용하여 데이터를 찾을 수 있습니다. ID 5, 마스터-마스터 복제 구성을 나타냅니다. 문제 없습니다.
두 마스터의 ID 자동 증가 오프셋이 다른 이유는 무엇인가요? 두 마스터가 동시에 삽입 요청을 받으면 ID가 충돌하지 않는지 확인할 수 있습니다. 실제로 이는 삽입된 데이터가 충돌하지 않는다는 것을 보장할 뿐이지 삭제 및 수정으로 인한 데이터 불일치를 보장할 수는 없습니다.
따라서 실제 애플리케이션 시나리오에서는 데이터 일관성을 보장하기 위해 하나의 마스터만 클라이언트에 노출될 수 있습니다.
这里借助keepalived来对上面的多主复制架构改造来实现MySQL的高可用。
keepalived的安装：
$ sudo apt-get install -y keepalived
keepalived.conf
$ cat /etc/keepalived/keepalived3314.conf! Configuration File for keepalived#简单的头部，这里主要可以做邮件通知报警等的设置，此处就暂不配置了；global_defs {
#notificationd LVS_DEVEL}#预先定义一个脚本，方便后面调用，也可以定义多个，方便选择；vrrp_script chk_haproxy {
script "/etc/keepalived/chkmysql.sh" #具体脚本路径
interval 2 #脚本循环运行间隔}#VRRP虚拟路由冗余协议配置vrrp_instance VI_1 { #VI_1 是自定义的名称；
state BACKUP #MASTER表示是一台主设备，BACKUP表示为备用设备【我们这里因为设置为开启不抢占，所以都设置为备用】
nopreempt #开启不抢占
interface eth0 #指定VIP需要绑定的物理网卡
virtual_router_id 11 #VRID虚拟路由标识，也叫做分组名称，该组内的设备需要相同
priority 130 #定义这台设备的优先级 1-254；开启了不抢占，所以此处优先级必须高于另一台
advert_int 1 #生存检测时的组播信息发送间隔，组内一致
authentication { #设置验证信息，组内一致
auth_type PASS #有PASS 和 AH 两种，常用 PASS
auth_pass asd #密码
}
virtual_ipaddress {
172.23.252.200 #指定VIP地址，组内一致，可以设置多个IP
}
track_script { #使用在这个域中使用预先定义的脚本，上面定义的
chk_haproxy }
#notify_backup "/etc/init.d/haproxy restart" #表示当切换到backup状态时,要执行的脚本
#notify_fault "/etc/init.d/haproxy stop" #故障时执行的脚本}/etc/keepalived/chkmysql.sh
$ cat /etc/keepalived/chkmysql.s.sh#!/bin/bashmysql -uroot -proot -P 3314 -e "show status;" > /dev/null 2>&1if [ $? == 0 ];then echo "$host mysql login successfully" exit 0else echo "$host login failed" killall keepalived exit 2fi
推荐学习：mysql视频教程
위 내용은 MySQL 복제 아키텍처에 대한 완전한 숙달의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
