怎么掌握MySQL复制架构
发布时间：2022-06-14 16:25:13 所属栏目：编程 来源：互联网
导读：本文小编为大家详细介绍怎么掌握MySQL复制架构，内容详细，步骤清晰，细节处理妥当，希望这篇怎么掌握MySQL复制架构文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。 一主多从复制架构 在实际应用场景中，MySQL复制90%以上都是一
|
本文小编为大家详细介绍“怎么掌握MySQL复制架构”，内容详细，步骤清晰，细节处理妥当，希望这篇“怎么掌握MySQL复制架构”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。 一主多从复制架构 在实际应用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式。 在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量的对实时性要求不是特别高的读请求通过负载均衡分部到多个从库上（对于实时性要求很高的读请求可以让从主库去读），降低主库的读取压力，如下图所示。 缺点： master不能停机，停机就不能接收写请求 slave过多会出现延迟 由于master需要进行常规维护停机了，那么必须要把一个slave提成master，选哪一个是一个问题？ 某一个slave提成master了，就存在当前master和之前的master数据不一致的情况，并且之前master并没有保存当前master节点的binlog文件和pos位置。 多主复制架构 多主复制架构解决了一主多从复制架构中master的单点故障问题。 怎么掌握MySQL复制架构 可以配合一个第三方的工具，比如keepalived轻松做到IP的漂移，这样master停机维护也不会影响写操作。 级联复制架构 一主多从中如果slave过多，会导致主库的I/O压力和网络压力会随着从库的增加而增长，因为每个从库都会在主库上有一个独立的BINLOG Dump线程来发送事件，而级联复制架构解决了一主多从场景下的，主库额外的I/O和网络压力。 怎么掌握MySQL复制架构 对比一主多从的架构，级联复制仅仅是从主库Master复制到少量的从库，其他从库再从这少量的从库中复制数据，这样就减轻了主库Master的压力。 当然也有缺点：MySQL的传统复制是异步的，级联复制场景下主库的数据是经历两次复制才到达其他从库中，期间的延迟要比一主多从复制场景下只经历一次复制的还大。 可以通过在二级slave上选择表引擎为BLACKHOLE来降低级联复制的延迟。顾名思义，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的user表里没有数据。 多主与级联复制结合架构 结合多主与级联复制架构，这样解决了单点master的问题，解决了slave级联延迟的问题。 多主复制架构的搭建 主机规划： master1：docker，端口3314 master2：docker，端口3315 master1的配置 配置文件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（这里的user来自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的配置 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) 可以发现master2中id的步长为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不冲突，其实这样只能保证插入数据不冲突，无法保证删除和修改导致的数据不一致。 所以在实际的应用场景中，只能暴露一个主给客户端才能保证数据的一致性。 MySQL高可用的搭建 这里借助keepalived来对上面的多主复制架构改造来实现MySQL的高可用。 （编辑：广西网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读
