N+1:N就是集群,1就是高可用,高可用的核心就是冗余,集群是保证服务最低使用标准的
一般是通过系统的可靠性和可维护性来衡量的
MTTF:平均无故障时间,这是衡量可靠性的
MTTR:衡量系统的可维护性的
HA=MTTF/(MTTF+MTTR)*100%
SLA: 99.999%:表示一年故障时间/宕机时间不超过6分钟
SLA可用性计算公式:可用性指标 = 正常请求 / 全部请求
1年 = 365天 = 8760小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
主从方式(非对称)
这种方式的组织形式通常都是通过两个节点和一个或多个服务器,其中一台作为主节点(active),另一台作为备份节点(standy),备份节点应该随时都在检测主节点的健康状况,
主节点发生故障,服务会自动切换到备份节点保障服务正常运行
对称方式
两个节点,都运行着不同的服务且相互备份,互相检测对方的健康,当任意一个节点发生故障,这个节点上的服务就会自动切换到另一节点
多机方式
包含多个节多个服务器,每个节点都要备份运行不同的服务,出现问题自动迁移
资源:两台同版本的MySQL数据库
主从实现的内部运行原理机制
第一步:主数据库服务器会把数据的修改记录记录进binlog日志,binlog一定要打开。
第二步:从库的I/O进行读取主库的binlog内容后存入自己的Relay Log中继日志中,这个I/O线程会和主库建立一个普通的客户端连接,然后主库启动一个二进制转储线程,I/O线程通过转储线程读取binlog更新事件,同步完毕后I/O进入sleep,有新的更新会再唤醒
第三步:从服务器的SQL进程会从Relay Log中读取事件并在从库中重放
服务器执行重放操作时是可以在配置里声明是否写入服务器的binlog日志中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vmdo6fxB-1593586624119)(C:\Users\16558\AppData\Roaming\Typora\typora-user-images\image-20200701101406918.png)]
配置主从服务器参数
在Master服务器上创建用于复制并授权的数据库账号
备份Master数据库并初始化Slave服务器数据
启动复制链路
Master服务器配置
# 慢查询开关
slow_query_log=ON
slow_query_log_file=/usr/local/slowlog/slow.log
slow_launch_time=4
long_query_time=3
# chown -R mysql:mysql /usr/local/slowlog/
binlog设置
server_id=213 #一般是取IP的后三位
log_bin=/usr/local/binlog/mysql-bin # 只需要给名字前缀
binlog_format=row
expire_logs_days=3
max_binlog_size=200m
Slave服务器配置
# 慢查询开关
slow_query_log=ON
slow_query_log_file=/usr/local/slowlog/slow.log
slow_launch_time=4
long_query_time=3
# chown -R mysql:mysql /usr/local/slowlog/
从库的主从设置
server_id=196
log_bin=/usr/local/binlog/mysql-bin
relay_log=/usr/local/relaylog/relay-bin
#当slave宕机后,如果relay log损坏了了,导致⼀一部分中继⽇日志没有处理理,则放弃所有未完成的,
重新获取执⾏行行,保证完整性
relay_log_recovery=1
#让从库数据只读, super⽤用户, super_read_only=on
read_only=on
#从库的复制链路路服务不不会随数据库重启⽽而重启,需要⼿手动启动
skip_slave_start=on
#确保数据⼀一致性,通过innoDB的崩溃恢复机制来保护哦
master_info_repository=TABLE
relay_log_info_repository=TABLE
#select * from mysql.slave_master_info;
#select * from mysql.slave_relay_log_info;
主从指明不同步的数据库,表(根据需要配置)
# Master
# 不同步数据库
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
# 只同步某一些数据库
binlog-do-db=icoding_admin
# Slave
# 复制哪些数据库
replicate-do-db=icoding_admin
replicate-do-db=game
# 不复制哪些数据库
replicate-ignore-db=mysql
replicate-ignore-db=information_schema
# 需要复制的表
replicate-do-table=game
#只复制哪个库的哪个表
replicate-wild-do-table=db_name.%
# 设定需要忽略的复制表
replicate-ignore-table=information_schema
# 忽略哪个库的哪个表
replicate-wild-ignore-table=mysql.%
主库授权(在Master上)
# Master授权给slave
mysql> use mysql;
mysql> grant replication slave on *.* to 'synuser'@'192.168.0.214' identified by '123456';
mysql> flush privileges;
初始化Slave数据
# Master和Slave的数据库版本要一致,Master<=Slave
mysqldump -uroot -p123456 -h127.0.0.1 --flush-logs --master-data=2 --routines --triggers --events --single-transaction --databases icoding_admin > mydb.sql
#CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=154; 就用导出的日志pos
创建复制链路
# 在slave上执行
mysql>
change master to master_host='192.168.0.213',
master_port=3306,
master_user='synuser',
master_password='123456',
master_log_file='mysql-bin.000004',
master_log_pos=154;
注意事项
主从复制的时候主从数据库的UUID不能一样,如果是镜像方式,启动前将UUID文件删除,会重新创建
cd /var/lib/mysql
cat auto.cnf # 将他删除
server-uuid=890980d9-b072-11ea-8ab8-00163e03668d
启动主从复制
# show slave status \G 可以查看主从复制的状态和日志错误
# 启动slave
mysql> start slave;
# 停止slave
mysql> stop slave;
和binlog步骤不同的地方:
主从服务器的参数有不同的地方
#在上⾯面的基础上,需要给主从服务器器都加上
gtid_mode=on
enforce_gtid_consistency=on #开启强制GTID的⼀一致性确保事务
GTID下复制链路的启动
mysql>
CHANGE MASTER TO
MASTER_HOST='192.168.0.102',
MASTER_PORT=3306,
MASTER_USER='syncuser',
MASTER_PASSWORD='123456',
MASTER_AUTO_POSITION=1;
启动GTID后以下数据库操作不可用
mixed格式默认采用statement,比如用到UUID(),ROW_COUNT()
异步复制:MySQL默认就是异步复制,性能最好,但主从复制的数据不一致性概率最大
同步复制:当客户端发过来一个请求后,只有当所有的从库都写到Relay Log中,才回复给前端事务完成,性能最差,但一致性很强
半同步复制:至少一个从库完成Relay Log写入后就返回事务完成给前端
主从上都要安装
mysql> install plugin rpl_semi_sync_master soname='semisync_master.so'
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout #单位是毫秒,如果主库等待从库回复超过这个时间就⾃自动切换为异步
主从一般都是实时的的同步的?
如果主库执行了一条更新语句 update tableName set score=99
,从库是不是也会被直接更新掉?
一般情况下,我们的从库对数据的实时性要求都不是非常高,如果我们有一个从库更新可以延时10分钟,运气好的话,在你拿到10分钟前的数据和你更新之间这个表没有操作,就可以完美解决掉。
设置一个从库,将延迟时间设置成我们能处理和反应的周期长度即可
mysql> stop slave;
mysql> change master to master_delay=600; #单位是秒, SQL_Delay: 600
mysql> start slave;