转:https://www.jianshu.com/p/b4f1cec71bbb
一、单个数据库服务器的缺点
-
数据库服务器存在单点问题;
-
数据库服务器资源无法满足增长的读写请求;
-
高峰时数据库连接数经常超过上限。
二、如何解决单点问题
-
增加额外的数据库服务器,组建数据库集群;
-
同一集群中的数据库服务器需要具有相同的数据;
-
集群中的任一服务器宕机后,其它服务器可以取代宕机服务器。
三、MySQL主从复制架构
1、主库将变更写入到主库的binlog中
-
一些MySQL版本并不会开启二进制日志,所以一定要检查是否开启;
-
如果刚开始没有开启,后面再进行开启的话,需要重启数据库才能生效,而且数据库的重启往往会对业务造成很大的影响;
-
尽管二进制日志对性能有稍许的影响,所以还是建议大家无论是否使用复制功能,都要开启MySQL二进制日志,因为增量备份也需要二进制日志。
2、从库的IO线程在指定位置读取主库binlog内容存储到本地的中继日志(Relay Log)中
要完成二进制日志的传输过程,MySQL会在从服务器上启动一个工作线程,称为IO线程,这个IO线程会跟主数据库建立一个普通的客户端连接,然后在主服务器上启动一个特殊的二进制转储线程称为binlogdown线程。
从库上的IO线程通过这个二进制转储线程来读取主库上的二进制事件,如果该事件追赶上主库,则会进入sleep状态,直到主库发起信号通知有新事件产生时,才会被唤醒,relay log的格式和binlog格式是完全相同的,
可以使用mysqlbinlog来读取relay log中的内容。
3、从库的SQL线程读取Relay Log日志中的内容,并在从库中重放
SQL线程所执行的事件,我们可以通过配置选项来决定是否要写入到从服务器的二进制日志中。
目前MySQL支持两种复制类型:
-
基于二进制日志点的复制
-
基于GTID的复制(MySQL>=5.7推荐使用)
四、MySQL主从配置步骤
1、配置主从数据库服务器参数
有些参数配置后需要数据库重启才能生效,为了不影响数据库的正常使用,我们最好在服务器上线的同时就把参数都配置好。特别是master服务器的参数,更应该作为服务器初始参数来进行配置。
master服务器:
slave 服务器:
2、在master服务器上创建用于复制的数据库账号
用于IO线程连接master服务器获取binlog日志,需要* REPLICATION SLAVE** 权限:
create user 'repl'@'ip段' identified by 'password';
grant replication slave on *.* to 'repl'@'ip段';
3、备份master服务器上的数据并初始化slave服务器数据
建议主从数据库服务器采用相同的MySQL版本;
建议使用全库备份的方式初始化slave数据。
采用相同版本的好处:
我们可以使用全备的方式来初始化slave数据,还可以避免不同版本之间的差异造成数据库同步失败的问题。
如果我们使用的主从复制的服务器MySQL版本不同,则一定要注意master上的版本一定要低于slave服务器,不然同步的时候就可能出现错误。
由于我们演示过程中的MySQL服务器都是使用的MySQL5.7,所以我们可以使用全备的方式进行:
mysqldump --master-data=2 -uroot -p -A --single-transaction -R --triggers
4、启动基于日志点的复制链路
在slave服务器上运行,MySQL命令:
CHANGE MASTER TO
MASTER_HOST= 'master_host_ip',
MASTER_USER= 'repl',
MASTER_PASSWORD = 'password',
MASTER_LOG_FILE='mysql_log_file_name',
MASTER_LOG_POS=xxxxxx;
5、启动基于GTID的复制链路
GTID:全局事务ID,GTID可以保证每一个在主上提交的事务,在复制集群中可以生成一个唯一的ID值,要使用基于GTID的复制,我们要在主从复制的配置文件中同时加入以下配置项。
MySQL配置:
gtid_mode=on
# 是否启动gtid模式,启动了此模式会在二进制日志中会额外记录每个事务的GTID标识符
enforce-gtid-consistency
# 强制gtid一致性,用于保证启动gtid后事务的安全
log-slave-updates = on
# mysql5.6一定要启用参数,5.7可以不启用
MySQL命令:
CHANGE MASTER TO
MASTER_HOST= 'master_host_ip',
MASTER_USER= 'repl',
MASTER_PASSWORD = 'password',
MASTER_AUTO_POSITION=1;
GTID复制的限制:
-
无法再使用create table ... select语句建立表,只能先create表,再insert数据;
-
无法在事务中使用create temporary table建立临时表;
-
无法使用关联更新同时更新事务表和非事务表。
4和5中选一个执行即可。
五. MySQL主从复制演示
1. 先对主服务器进行配置
由于主服务器一直在运行着,在生产环境中主服务器是很少会重启的,如果主服务器重启,会造成正常的业务访问的中断,所以在服务器启动之前就启动了二进制日志。
这里不需要重启主服务器了,由于主服务器的默认server_id=1,我们虽然在配置文件中更改了它的值 ,但实际运行环境中并没有改变。
我们可以查看一下当前server_id:
mysql> show variables like '%server_id%';
可以通过以下命令动态的进行修改:
mysql> set global server_id = 100;
2. 再对从服务器进行配置
修改完从服务器配置后,重启MySQL服务器。如果使用的是MySQL5.7版本的需要注意:
-
MySQL5.7增加了server-uuid值,默认情况下载auto.cnf文件中,如果是使用的镜像的方式安装,可能大家的uuid一样 ,所以需要把auto.cnf文件删除掉。MySQL重启后会自动重新生成uuid的值,这样就可以保证不同服务器上的MySQL实例的uuid的值是不一样的;
-
如果server-uuid的值相同,主从复制会出现问题。
以上我们就完成了主从复制的配置,接下来我们要在主服务器上建立复制账号。
3. 在MySQL主服务器上建立MySQL复制账号
mysql> create user 'dba_repl'@'192.168.3.%' identified by '123456';
mysql> grant replication slave on *.* to 'dba_repl'@'192.168.3.%';
4. 建立好复制账号以后,通过mysql主服务器上的全备初始化从服务器上数据
进行全备:
[root@localhost data]# cd /data/db_backup/
[root@localhost db_backup]# mysqldump -uroot -p --master-data=1 --single-transaction --routines --triggers --events --all-databases > all.sql
Enter password:
将其拷贝到从服务器上:
[root@localhost db_backup]# scp all.sql root@192.168.3.101:/root
在从服务器上恢复备份进行初始化:
[root@Node2 ~]# mysql -uroot -p < all.sql
初始化完成后,准备。
5. 从服务器进行基于日志点的复制链路的配置
mysql> change master to
master_host='192.168.3.100',
master_user='dba_repl',
master_password='123456',
MASTER_LOG_FILE='mysql-bin.000017',
MASTER_LOG_POS=663;
MASTER_LOG_FILE和MASTER_LOG_POS的值从全备文件中的CHANGE MASTER中获取
以上复制链路的配置完成。
启动slave:
mysql> start slave;
检查是否启动成功状态:
mysql> show slave status \G
显示:
Relay_Master_Log_File: mysql-bin.000017Slave_IO_Running:YesSlave_SQL_Running: Yes
说明启动成功了,可以在主服务器上插入数据,在从服务上查看数据是否同步过来了。
六. 主从复制的一些缺点
虽然主从复制增加了一个数据库副本,但从数据库和主数据库的数据最终会是一致的。之所以说是最终一致,因为MySQL复制是异步的,正常情况下主从复制数据之间会有一个微小的延迟。
通过这个数据库副本看似解决了数据库单点问题,但并不完美:因为这种架构下,如果主服务器宕机,需要手动切换从服务器,业务中断不能忍受,不能满足应用高可用的要求。
相关推荐
当遇到MySQL单点故障中,也能在短时间内实现故障切换。本文就MySQL的内建的复制功能进行阐述。 版本 MySQl: 5.7.17 CentOS: 7.4.1708 Docker: 1.13.1 概述 MySQL复制数据流程: 主库在数据更新提交事务之前,...
当单台MYSQL服务器无法满足当前网站流量时的优化方案。需要搭建mysql集群技术。 一、功能: 当向主服务器插入|修改|删除数据时,数据会自动同步到从服务器。 注意:主从复制是单向的,只能主 -> 从 分为两种类型:...
关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用mysql...
为了解决单点模式的风险,主备模式产生。目前,主备模式应该是各个线上服务系统的最低配置了,比如你在各个云平台购买的数据库服务一般都会开启备份功能。一旦主节点出现问题,还可以切换到备份节点,不至于整个系统...
MySQL数据库是目前开源应用最大的关系型数据库,有海量的应用将数据存储在MySQL数据库中。...Replication用两个或以上的实例搭建了MySQL主从复制集群,提供单点写入,多点读取的服务,实现了读的scale out。
MySQL集群有一些创建高可用性系统的专用功能: 节点恢复 日志 检查点 系统恢复 热备份及恢复 无单点故障 故障转移 分区 联机操作 硬件配置: 一台mysql + manager server ,两台 数据存储节点 3台 我们系统的需求:...
2)通过数据库代理中间件心跳监测,解决单点故障问题; 3)通过代理中间件将查询语句分发到各个slave节点进行查询,并汇总结果 4)通过分表分库解决读写效率问题 3、非关系型数据库的解决方案? 对于Nosql数据库,以...
2)通过数据库代理中间件心跳监测,解决单点故障问题; 3)通过代理中间件将查询语句分发到各个slave节点进行查询,并汇总结果 4)通过分表分库解决读写效率问题 1.1大规模数据如何检索? 当系统数据量上了10亿、...
资源包用途:在centos8的系统安上安装mysql8.0.18的数据库主从群集。(因文件太大,暂放在云盘中,此处仅下载地址) centos8正式版出来后,就试用了一下,并安装的mysql8.0.8的数据库。发现它与在centos7上有一...
mysql主从数据库部署 memcache扩展改用libmemcached; 引入消息机制(MemcaheQ),异步发表微博; 微博推送用户分级,优先推送重点用户; InnoDB搜索引擎 按时间分表,索引以mysql存放,内容采用nosql存储 问题...
防止单点隐患 17 方便系统扩容 17 安全可控,成本可控 17 分布式方案 18 分库&拆表方案 18 反范式设计(冗余结构设计) 20 主从架构 21 故障转移处理 22 缓存方案 22 缓存结合数据库的读取 22 缓存结合数据库的写入
Mysql 执行优化 2 ...防止单点隐患 11 方便系统扩容 11 安全可控,成本可控 11 分布式方案 12 分库&拆表方案 12 主从架构 14 故障转移处理 15 缓存方案 15 缓存结合数据库的读取 15 缓存结合数据库的写入 15
那么解决问题,就得说到方案。但是方案有很多,我们该怎么选择呢? 优化与方案 基本上,我们优化要从几个关键字入手: 短距离 , 少数据 , 分散压力 。 短距离 所谓的短距离,指的是从前端到数据库的路径要短。 ...
session跨域共享及企业级单点登录解决方案实战 分布式事务解决方案实战 高并发下的服务降级、限流实战 基于分布式架构下分布式锁的解决方案实战 分布式架构实现分布式定时调度 分布式架构-中间件 分布式消息...
在企业中,一般系统架构的瓶颈会出现在数据库这一部分,mysql主从架构在很大程度上解决了这部分瓶颈,但是在mysql主从同步的架构也存在很多问题;比如:1. 关于数据写入部分(也就是主库)往往很难做到扩展,虽然很多大公司...
1.5.1 生产环境不能用强制命令关闭 mysql 服务 .......................................................22 1.5.2 下面来介绍优雅关闭数据库方法: ................................................................