MySql的高可用方案

  • mysql架构的重要性
  • 一、MYSQL主从架构
    • 1.环境介绍
    • 2.搭建主从集群
      • 2.1.理论基础
      • 2.2 主从同步原理
      • 2.3.配置mysql主库(master)
      • 2.3.配置mysql从库(slave)
      • 2.4主从集群测试
  • 二、 集群搭建扩展
    • 1.全库同步与部分同步
    • 2.读写分离配置
    • 3.其他集群方式
      • 3.1互为主从的搭建
      • 3.2.GTID同步集群
    • 4.机器扩容
  • 三、半同步复制
    • 1.半同步复制
    • 2.搭建半同步复制集群
  • 四,主从架构的数据延迟问题
  • 五、MYSQL的高可用方案
    • 1、MMM
    • 2、MHA
    • 3、MGR
  • 六、分库分表
    • 1、分库分表有什么用
    • 2、分库分表的方式
    • 3、分库分表的缺点
    • 4、什么时候需要分库分表?
    • 5、常见的分库分表组件

mysql架构的重要性

MySQL是现在互联网最常用的开源数据库产品。但是我们平常开发使用,大都是用的单机服务。而在实际生产中,往往数据量会极为庞大,并且数据的安全性要求也更高,这样单机的MySQL,不管是性能还是安全都是达不到要求的。所以在生产环境中,MySQL必须是要搭建一套主从复制的架构,同时可以基于一些工具实现高可用架构。然后,在此基础上,就可以基于一些中间件实现读写分离架构。最后如果数据量非常大,还必须可以实现分库分表的架构。 当然,MySQL的这些架构搭建还是比较复杂的,通常会由专门的运维人员来搭建。所以这次实验的目的,并不是要大家就学会去搭建MySQL集群,而是带大家对生产环境下的MySQL架构有一定的理解,能够在自己的生产项目中运用上MySQL的生产架构。同时,也是为后面的ShardingSphere分库分表打下基础。

一、MYSQL主从架构

1.环境介绍

两台服务器,均安装CentOS7。
​ 1、192.168.56.120 作为mysql主节点部署
​ 2、192.168.56.121 作为mysql从节点部署
mysql版本:mysql-5.7.34-linux-glibc2.12-x86_64
在linux上安装mysql这里就不介绍了,网上有很多的博客,可以百度或者google就可以看到很多,我这里提供一个不错的博客地址:
Linux安装MySQL5.7_吃四碗饭的嘤嘤怪的博客-CSDN博客_linux安装mysql5.7
为了便于使用,两个mysql服务需要打开远程登录权限,开启方式需要在本机登录mysql,执行以下语句。

#开启远程登录
use mysql;
update user set host='%' where user='root';
flush privileges;

2.搭建主从集群

2.1.理论基础

主从架构有什么用?通过搭建MySQL主从集群,可以缓解MySQL的数据存储以及访问的压力。
1、数据安全
​ 给主服务增加一个数据备份。基于这个目的,可以搭建主从架构,或者也可以基于主从架构搭建互主的架构。
2、读写分离
​ 对于大部分的JAVA业务系统来说,都是读多写少的,读请求远远高于写请求。这时,当主服务的访问压力过大时,可以将数据读请求转为由从服务来分担,主服务只负责数据写入的请求,这样大大缓解数据库的访问压力。
​ 要理解,MySQL的主从架构只是实现读写分离的一个基础。实现读写分离还是需要一些中间件来支持,比如ShardingSphere。
3、故障转移-高可用
​ 当MySQL主服务宕机后,可以由一台从服务切换成为主服务,继续提供数据读写功能。
​ 对于高可用架构,主从数据的同步也只是实现故障转移的一个前提条件,要实现MySQL主从切换,还需要依靠一些其他的中间件来实现。比如MMM、MHA、MGR。
​ 在一般项目中,如果数据库的访问压力没有那么大,那读写分离不一定是必须要做的,但是,主从架构和高可用架构则是必须要搭建的。

2.2 主从同步原理


上图就是一个mysql的主从架构,从这个主从架构中我们可以知道master节点在自己的数据文件目录会生成一个bin log日志文件,每当master节点上发生了增删改查操作的时候都会同步写入bin log日志文件,然后slave节点会从master节点同步数据,同步数据的方式就是slave和master之间开启了一个IO 线程,这个IO线程主要创建TCP连接的,而且这个是一个长连接。这时,主库上会有一个IO dump线程会将bin log日志文件通过SLAVE与master创建的这个tcp了将bin log日志文件传给从库,从库接受到这个bin log日志文件会将日志文件的内容写入从库的relay log日志文件,而这个时候从库中是由一个 SQL 的线程会读取relay log文件内容然后进行操作重演(log中保存的是crud的sql语句操作记录)从而达到数据恢复的目的;通常我们所说的读写分离就是必须要在mysql的主从架构上来搭建。
MySQL的bin log不光可以用于主从同步,还可以用于缓存数据同步等场景。
例如Canal,可以模拟一个slave节点,向MySQL发起binlog同步,然后将数据落地到Redis、Kafka等其他组件,实现数据实时流转。

2.3.配置mysql主库(master)

首先,配置主节点的mysql配置文件: /etc/my.cnf 这一步需要对master进行配置,主要是需要打开binlog日志,以及指定severId。我们打开MySQL主服务的my.cnf文件,在文件中一行server-id以及一个关闭域名解析的配置。然后重启服务。

[mysqld]
server-id=10
#开启binlog
log_bin=master-bin
log_bin-index=master-bin.index
skip-name-resolve
# 设置连接端口
port=3306
# 设置mysql的安装目录
basedir=/usr/local/mysql/mysql-5.7.34
# 设置mysql数据库的数据的存放目录
datadir=/data/mysql/
socket=/tmp/mysql.sock
log-error=/data/mysql/mysql.err
pid-file=/data/mysql/mysql.pid
# 允许最大连接数
max_connections=200
# 允许连接失败的次数。
max_connect_errors=10
# 服务端使用的字符集默认为UTF8
character-set-server=utf8
# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_plugin=mysql_native_password

​ 重启MySQL服务, service mysql restart
​ 然后,我们需要给root用户分配一个replication slave的权限

#登录主数据库
mysql -u root -p
GRANT REPLICATION SLAVE ON *.* TO 'root'@'%';
flush privileges;
#查看主节点同步状态:
show master status;在实际生产环境中,通常不会直接使用root用户,而会创建一个拥有全部权限的用户来负责主从同步。

这个时候可以看下master的节点状态

这个指令结果中的File和Position记录的是当前日志的binlog文件以及文件中的索引。
​ 而后面的Binlog_Do_DB和Binlog_Ignore_DB这两个字段是表示需要记录binlog文件的库以及不需要记录binlog文件的库。目前我们没有进行配置,就表示是针对全库记录日志。这两个字段如何进行配置,会在后面进行介绍。
开启binlog后,数据库中的所有操作都会被记录到datadir当中,以一组轮询文件的方式循环记录。而指令查到的File和Position就是当前日志的文件和位置。而在后面配置从服务时,就需要通过这个File和Position通知从服务从哪个地方开始记录binLog。

开启binlog后,数据库中的所有操作都会被记录到datadir当中,以一组轮询文件的方式循环记录。而指令查到的File和Position就是当前日志的文件和位置。而在后面配置从服务时,就需要通过这个File和Position通知从服务从哪个地方开始记录binLog。

2.3.配置mysql从库(slave)

下一步,我们来配置从服务mysql。 我们打开mysql的配置文件my.cnf,修改配置文件:

[mysqld]
server-id=20
#打开MySQL中继日志
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
#打开从服务二进制日志
log-bin=mysql-bin
#使得更新的数据写进二进制日志中
log-slave-updates=1
# 设置3306端口
port=3306
# 设置mysql的安装目录
basedir=/usr/local/mysql/mysql-5.7.34
# 设置mysql数据库的数据的存放目录
datadir=/data/mysql/
socket=/tmp/mysql.sock
log-error=/data/mysql/mysql.err
pid-file=/data/mysql/mysql.pid
# 允许最大连接数
max_connections=200
# 允许连接失败的次数。
max_connect_errors=10
# 服务端使用的字符集默认为UTF8
character-set-server=utf8
# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_plugin=mysql_native_password

配置说明:主要需要关注的几个属性:
server-id:服务节点的唯一标识
relay-log:打开从服务的relay-log日志。
log-bin:打开从服务的bin-log日志记录。
然后我们启动mysqls的服务,并设置他的主节点同步状态。

#登录从服务
mysql -u root -p;
#设置同步主节点:mysql> CHANGE MASTER TO-> MASTER_HOST='192.168.56.120',-> MASTER_PORT=3306,-> MASTER_USER='root',-> MASTER_PASSWORD='123456',-> MASTER_LOG_FILE='master-bin.000002',-> MASTER_LOG_POS=154;
Query OK, 0 rows affected, 2 warnings (1.74 sec
#开启slave
start slave;
#查看主从同步状态
show slave status;
或者用 show slave status \G; 这样查看比较简洁

注意,CHANGE MASTER指令中需要指定的MASTER_LOG_FILE和MASTER_LOG_POS必须与主服务中查到的保持一致。
并且后续如果要检查主从架构是否成功,也可以通过检查主服务与从服务之间的File和Position这两个属性是否一致来确定。

Master_Log_File: master-bin.000002:表示从库对应的主库的日志文件是master-bin.000002
Read_Master_Log_Pos: 154:表示读取master主库的bin log日志文件的位置是154;
Relay_Log_File: slave-relay-bin.000002:表示从库的的relay log文件的名称
Relay_Log_Pos: 321:表示从库的relay log文件的读取位置(sql线程读取进行sql从演)
Relay_Master_Log_File: master-bin.000002:表示relay log从主库读取的bin log日志文件;
Slave_IO_Running:yes:表示从节点的的IO线程正常(用于接收主库的bin log日志文件写入从库的relay log的线程)
Slave_SQL_Running:yes:表示从库的内部SQL线程正常(用于读取relay log文件进行sql从演的线程)

2.4主从集群测试

测试时,我们先用showdatabases,查看下两个MySQL服务中的数据库情况

这个时候我们在主库上建立了一个数据库mslademo,再查看主库和从库,发现主从都有了这个数据库,说明是同步成功的

接下来我们继续在mslademo这个数据库中创建一个表,并插入一条数据。

mysql> use mslademo
Database changed
mysql> create table demo(id int  not null);
Query OK, 0 rows affected (0.02 sec)
mysql> insert into demo values(1);
Query OK, 1 row affected (0.11 sec)

这个时候再看看主从表中是否有了数据

从上面的实验过程看到,我们在主服务中进行的数据操作,就都已经同步到了从服务上。这样,我们一个主从集群就搭建完成了。
另外,这个主从架构是有可能失败的,如果在slave从服务上查看slave状态,发现Slave_SQL_Running=no,就表示主从同步失败了。这有可能是因为在从数据库上进行了写操作,与同步过来的SQL操作冲突了,也有可能是slave从服务重启后有事务回滚了。
如果是因为slave从服务事务回滚的原因,可以按照以下方式重启主从同步:

mysql> stop slave ;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> start slave ;

而另一种解决方式就是重新记录主节点的binlog文件消息

mysql> stop slave ;
mysql> change master to .....
mysql> start slave ;

但是这种方式要注意binlog的文件和位置,如果修改后和之前的同步接不上,那就会丢失部分数据。所以不太常用。
在这里需要明白的的一个事情就是这样简单的主从架构中,如果你在主库上进行了插入修改删除等操作,那么这些操作带来的数据变化是不会主动同步到主库上的,所以就需要你在应用中进行控制,控制读写分离了,如果你的应用不小心将数据写入了从库,那么这个时候带来的问题就很大了,比如下面:

像上面的步骤一样,这样做的后果带来的就是数据同步异常,因为demo没有加任何索引,所以插入没有问题,但是真正的业务场景中不可能没有索引,所以如果使用了主从架构,就必须先要读写分离或者还有一种方案就是互相主从,两个节点即使从节点又是主节点,这样的配置也是可以配置的。

二、 集群搭建扩展

1.全库同步与部分同步

上面我们在主节点master上可以看master的节点状态 show master status;
看到了有两个属性,一个是Binlog_Do_DB ,一个是 Binlog_Ignore_DB ,什么意思呢?这就是涉及到全库同步还是部分同步,mysql的master节点默认是全库同步,全库同步的意思就是mysql默认的数据库都给同步了,比如:

这些数据库都全部同步了,那这样肯定不行啊,我们的目的是同步自己的数据库,比如mslademo这个数据库,其他数据库可能是其他业务的或者系统的数据库,我们不用同步,所以Binlog_Do_DB 和Binlog_Ignore_DB 就是用来配置要同步那些数据库和忽略那些数据库的
首先在Master端:在my.cnf中,可以通过以下这些属性指定需要针对哪些库或者哪些表记录binlog

#需要同步的二进制数据库名
binlog-do-db=mslademo
##只保留7天的二进制日志,以防磁盘被日志占满(可选)
expire-logs-days  = 7
##不备份的数据库
binlog-ignore-db=information_schema
binlog-ignore-db=performation_schema
binlog-ignore-db=sys

配置完重启可以看到:
这样的情况下就只同步我们的业务数据库mslademo了,忽略的数据库可以不用配置
然后在Slave端:在my.cnf中,需要配置备份库与主服务的库的对应关系:

#如果salve库名称与master库名相同,使用本配置
replicate-do-db=mslademo
#如果master库名[mslademo]与salve库名[mslademo01]不同,使用以下配置[需要做映射]
#replicate-rewrite-db = masterdemo -> masterdemo01
#如果不是要全部同步[默认全部同步],则指定需要同步的表
#replicate-wild-do-table=mslademo01.t_dict
#replicate-wild-do-table=mslademo01.t_num

2.读写分离配置

我们要注意,目前我们的这个MySQL主从集群是单向的,也就是只能从主服务同步到从服务,而从服务的数据表更是无法同步到主服务的。

所以,在这种架构下,为了保证数据一致,通常会需要保证数据只在主服务上写,而从服务只进行数据读取。这个功能,就是大名鼎鼎的读写分离。但是这里要注意下,mysql主从本身是无法提供读写分离的服务的,需要由业务自己来实现。这也是我们后面要学的ShardingSphere的一个重要功能。
到这里可以看到,在MySQL主从架构中,是需要严格限制从服务的数据写入的,一旦从服务有数据写入,就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。
如果需要限制用户写数据,我们可以在从服务中将read_only参数的值设为1( set global read_only=1; )。这样就可以限制用户写入数据。但是这个属性有两个需要注意的地方:
1、read_only=1设置的只读模式,不会影响slave同步复制的功能。 所以在MySQL slave库中设定了read_only=1后,通过 “show slave status\G” 命令查看salve状态,可以看到salve仍然会读取master上的日志,并且在slave库中应用日志,保证主从数据库同步一致;

2、read_only=1设置的只读模式, 限定的是普通用户进行数据修改的操作,但不会限定具有super权限的用户的数据修改操作。 在MySQL中设置read_only=1后,普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时,都会报出数据库处于只读模式不能发生数据变化的错误,但具有super权限的用户,例如在本地或远程通过root用户登录到数据库,还是可以进行数据变化的DML操作; 如果需要限定super权限的用户写数据,可以设置super_read_only=0。另外 如果要想连super权限用户的写操作也禁止,就使用"flush tables with read lock;",这样设置也会阻止主从同步复制!

3.其他集群方式

mysql的主从架构已经搭建好了,但是这样只能单向同步,也就是说从库是不能写入数据和修改数据的,因为从库更改了数据不能同步到主库中,那么是不是可以搭建一个互为主库的架构呢?这个是完全可以的,可以互为主库和互为从库,如果在生产中这种架构还是不能满足的话还可以搭建一个环形的主从架构,但是这种环形的主从架构会有缺陷,要是其中的节点挂了,那么需要手动去从新建立关系。

但是这种环形的架构有种缺陷就是只要其中的一个节点挂了,那么就需要手动的去维护新的一个关系,无法达到高可用,不过在一般系统压力不是非常大的项目中,可以采用主从架构,互为主从就可以了,互为主从的架构下,主节点和从节点都可以写入数据,不管那个节点挂了,另外的节点都能进行读写。但是如果采用环形的架构上能够规避节点的宕机情况,那么带来的架构好处是显而易见的,就上图来说,如果第二个节点写入了数据,那么第一个节点是没法同步的,但是可以同步给第三个节点,第三个节点又是第四个节点的主节点,第四个节点又是第一个节点的主节点,所以不管哪个节点写入数据都能够完成整体的数据的同步,这就是环形架构带来的多主多从的好处,可以缓解数据库的压力,我们知道在目前的互联网架构中,决定了一个系统的下线就是数据库的能力,所以设计一个好的数据库架构是多么的重要,但是这种主从架构的环形设计要充分考虑到节点宕机的情况,如果想要实现高可用的架构方案,可以考虑MMM,MHA,MGR等高可用的方案,但是比较费钱,根据自己系统的情况去考虑吧。

3.1互为主从的搭建

前面我在192.168.56.120和121已经搭建了一个主从架构了,那么如果要搭建一个互为主从的架构怎么做呢?首先120已经是主了,121是从了,搭建互主集群只需要按照上面的方式,在主服务上打开一个slave进程,并且指向slave节点的binlog当前文件地址和位置。
在主节点执行:

mysql> CHANGE MASTER TO-> MASTER_HOST='192.168.56.121',-> MASTER_PORT=3306,-> MASTER_USER='root',-> MASTER_PASSWORD='123456',-> MASTER_LOG_FILE='mysql-bin.000004',-> MASTER_LOG_POS=154;
Query OK, 0 rows affected, 2 warnings (2.41 sec)

然后在主节点120看slave的状态:

可以看到关系已经建立起来了,这个时候我们在原来的从节点121上插入数据看下原来的主节点是否能够同步数据:

可以看到mysql的互为主从就已经搭建好了,我觉得在一般大的规模中的数据库就已经能够满足这种架构了,具体还是看公司自己的成本是否需要上MMM、MHA、MGR,根据实际情况来看吧,适合自己的架构才是最优方案而不是一味的最求架构的完整性。

3.2.GTID同步集群

上面我们搭建的集群方式,是基于Binlog日志记录点的方式来搭建的,这也是最为传统的MySQL集群搭建方式。而在这个实验中,可以看到有一个Executed_Grid_Set列,暂时还没有用上。实际上,这就是另外一种搭建主从同步的方式,即GTID搭建方式。这种模式是从MySQL5.6版本引入的。
​ GTID的本质也是基于Binlog来实现主从同步,只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID,全局唯一并且趋势递增,他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。
​ 在基于GTID的复制中,首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值,然后主库会有把所有没有在从库上执行的事务,发送到从库上进行执行,并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次,这样可以避免由于偏移量的问题造成数据不一致。他的搭建方式跟我们上面的主从架构整体搭建方式差不多。只是需要在my.cnf中修改一些配置。
在主节点上:

gtid_mode=on
enforce_gtid_consistency=1

​ 在从节点上:

gtid_mode=on
enforce_gtid_consistency=1
log_slave_updates=1

配置改好以后重启主从mysql服务,然后登陆从节点121,登陆从库,开启主从复制,此时已经不需要指定master_log_file和master_log_pos了,而是通过参数master_auto_position=1去指定自动找到GTID进行复制。

mysql>stop slave;
mysql> change master to-> master_host='192.168.56.120',-> -> master_port=3306,-> master_user='root',-> master_password='123456',-> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.38 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

这样就开启了主从复制通过GTID的方式了,我们在主库插入了几条数据过后,看下master的状态:

可以看到executed_Gtid_set已经有值了,后面的是事务ID 1-3,然后再看下从库:

mysql> show slave status \G;
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.56.120Master_User: rootMaster_Port: 3306Connect_Retry: 60Master_Log_File: master-bin.000006Read_Master_Log_Pos: 943Relay_Log_File: slave-relay-bin.000002Relay_Log_Pos: 1158Relay_Master_Log_File: master-bin.000006Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB: mslademoReplicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0Last_Error: Skip_Counter: 0Exec_Master_Log_Pos: 943Relay_Log_Space: 1365Until_Condition: NoneUntil_Log_File: Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error: Last_SQL_Errno: 0Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 10Master_UUID: e7f4fe3a-ab43-11eb-878e-080027b66296Master_Info_File: /data/mysql/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: e7f4fe3a-ab43-11eb-878e-080027b66296:1-3Executed_Gtid_Set: e7f4fe3a-ab43-11eb-878e-080027b66296:1-3Auto_Position: 1Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version:
1 row in set (0.00 sec)ERROR:
No query specified

Retrieved_Gtid_Set: e7f4fe3a-ab43-11eb-878e-080027b66296:1-3
Executed_Gtid_Set: e7f4fe3a-ab43-11eb-878e-080027b66296:1-3
已经建立好了主从的关系了,并且事务ID也已经同步过来了,这种方式在主从架构中应该是用的最多了,根据事务ID来同步数据

4.机器扩容

我们现在已经搭建成功了一主一从的MySQL集群架构,那要扩展到一主多从的集群架构,其实就比较简单了,只需要增加一个binlog复制就行了。
​ 但是如果我们的集群是已经运行过一段时间,这时候如果要扩展新的从节点就有一个问题,之前的数据没办法从binlog来恢复了。这时候在扩展新的slave节点时,就需要增加一个数据复制的操作。
​ MySQL的数据备份恢复操作相对比较简单,可以通过SQL语句直接来完成。具体操作可以使用mysql的bin目录下的mysqldump工具。

mysqldump -u root -p --all-databases > backup.sql
#输入密码

通过这个指令,就可以将整个数据库的所有数据导出成backup.sql,然后把这个backup.sql分发到新的MySQL服务器上,并执行下面的指令将数据全部导入到新的MySQL服务中。

mysql -u root -p < backup.sql
#输入密码

​ 这样新的MySQL服务就已经有了所有的历史数据,然后就可以再按照上面的步骤,配置Slave从服务的数据同步了。

三、半同步复制

现在为止,我们已经可以搭建MySQL的主从集群,互主集群,但是我们这个集群有一个隐患,就是有可能会丢数据。这是为什么呢?这要从MySQL主从数据复制分析起。

如上图,我们知道mysql的主从复制原理是master有一个dump线程会将bin log通过和slave建立的tcp连接发送过去,这个是一个异步的操作,也就是说客户端提交的sql操作其实在主库中是安装流程执行的,期间根本不会关心dump线程是否把bin log同步过去了,那么这样就会出现一个问题,局势dump线程在同步bin log日志的时候,主服务器挂了,那么从服务器就丢失数据了,那这种问题要怎么来解决呢?这个就依靠mysql的半同步复制来解决这个问题。

1.半同步复制

半同步复制是介于异步复制和完全同步复制之前的机制,就是说当客户端提交事务请求过后,主库完成了事务的提交并且写入了bin log日志以后,这个时候不是马上返回给客户端,而是通过dump线程同步将bin log发送给从库,从库接受到过后写入relay log,然后再返回,如果从库由于其他原因半天返回的话,主库有一个等待的时间是10s,默认就是10s,10s过后没有收到ack就直接返回给客户端了,这个时候的同步方式就开始降级为异步复制了。

这种半同步复制在一定程度上保证了数据的安全性和完整性,但是这种情况也不是完全的保证,它只能保证bin log传输到了从库,只保证事务提交后的binlog至少传输到了一个从库,并且并不保证从库应用这个事务的binlog是成功的;再者这种情况还会降级主库写入数据的性能,多了一次tcp的发送和接受,而且还需要等待从库的返回,整个服务的性能是会有所下降的。而当从服务出现问题时,主服务需要等待的时间就会更长,要等到从服务的服务恢复或者请求超时才能给用户响应。

2.搭建半同步复制集群

半同步复制需要基于特定的扩展模块来实现。而mysql从5.5版本开始,往上的版本都默认自带了这个模块。这个模块包含在mysql安装目录下的lib/plugin目录下的semisync_master.so和semisync_slave.so两个文件中。需要在主服务上安装semisync_master模块,在从服务上安装semisync_slave模块。

首先我们登陆主服务,安装semisync_master模块:

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.39 sec)mysql> show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | OFF        |
| rpl_semi_sync_master_timeout              | 10000      |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.01 sec)mysql>

rpl_semi_sync_master_enabled:表示是否开启半同步复制
| rpl_semi_sync_master_timeout :开启半同步复制的主从的等待时间
| rpl_semi_sync_master_trace_level :日志的打印级别
| rpl_semi_sync_master_wait_point :半同步复制方式,半同步复制有两种方式,一种是我们现在看到的这种默认的AFTER_SYNC方式。这种方式下,主库把日志写入binlog,并且复制给从库,然后开始等待从库的响应。从库返回成功后,主库再提交事务,接着给客户端返回一个成功响应。而另一种方式是叫做AFTER_COMMIT方式。他不是默认的。这种方式,在主库写入binlog后,等待binlog复制到从库,主库就提交自己的本地事务,再等待从库返回给自己一个成功响应,然后主库再给客户端返回响应。

开启半同步负复制:


mysql> set global rpl_semi_sync_master_enabled=ON;
Query OK, 0 rows affected (0.00 sec)mysql> show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
| rpl_semi_sync_master_timeout              | 10000      |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.00 sec)

所有的参数都可以使用set global 参数名称=值来设置。

然后我们登陆从服务,安装smeisync_slave模块

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.04 sec)mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | OFF   |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.01 sec)mysql> stop slave;
Query OK, 0 rows affected (2.02 sec)mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

从库的参数就比较简单了,但是需要注意的是slave端的安装过程基本差不多,不过要注意下安装完slave端的半同步插件后,需要重启下slave服务。

四,主从架构的数据延迟问题

在我们搭建的这个主从集群中,有一个比较隐藏的问题,就是这样的主从复制之间会有延迟。这在做了读写分离后,会更容易体现出来。即数据往主服务写,而读数据在从服务读。这时候这个主从复制延迟就有可能造成刚插入了数据但是查不到。当然,这在我们目前的这个集群中是很难出现的,但是在大型集群中会很容易出现。
​ 出现这个问题的根本在于:面向业务的主服务数据都是多线程并发写入的,而从服务是单个线程慢慢拉取binlog,这中间就会有个效率差。所以解决这个问题的关键是要让从服务也用多线程并行复制binlog数据。
​ MySQL自5.7版本后就已经支持并行复制了。可以在从服务上设置slave_parallel_workers为一个大于0的数,然后把slave_parallel_type参数设置为LOGICAL_CLOCK,这就可以了。

mysql> show global variables like 'slave_parallel%';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| slave_parallel_type    | DATABASE |
| slave_parallel_workers | 0        |
+------------------------+----------+
2 rows in set (0.00 sec)mysql> set global slave_parallel_type='LOGICAL_CLOCK';
Query OK, 0 rows affected (0.00 sec)mysql> set global slave_parallel_workers=3;
Query OK, 0 rows affected (0.00 sec)
mysql> start slave;
Query OK, 0 rows affected (2.05 sec)
mysql> show global variables like 'slave_parallel%';
+------------------------+---------------+
| Variable_name          | Value         |
+------------------------+---------------+
| slave_parallel_type    | LOGICAL_CLOCK |
| slave_parallel_workers | 3             |
+------------------------+---------------+
2 rows in set (0.01 sec)
mysql>

这样就开启了,记得要修改全局参数的时候都先要stop slave;修改完毕以后在开启slave start slave;

五、MYSQL的高可用方案

我们之前的MySQL服务集群,都是使用MySQL自身的功能来搭建的集群。但是这样的集群,不具备高可用的功能。即如果是MySQL主服务挂了,从服务是没办法自动切换成主服务的。而如果要实现MySQL的高可用,需要借助一些第三方工具来实现。
​ 常见的MySQL集群方案有三种: MMM、MHA、MGR。这三种高可用框架都有一些共同点:
对主从复制集群中的Master节点进行监控
自动的对Master进行迁移,通过VIP(虚拟IP地址)。
重新配置集群中的其它slave对新的Master进行同步

1、MMM

MMM(Master-Master replication managerfor Mysql,Mysql主主复制管理器)是一套由Perl语言实现的脚本程序,可以对mysql集群进行监控和故障迁移。他需要两个Master,同一时间只有一个Master对外提供服务,可以说是主备模式。
​ 他是通过一个VIP(虚拟IP)的机制来保证集群的高可用。整个集群中,在主节点上会通过一个VIP地址来提供数据读写服务,而当出现故障时,VIP就会从原来的主节点漂移到其他节点,由其他节点提供服务。

优点:
提供了读写VIP的配置,使读写请求都可以达到高可用
工具包相对比较完善,不需要额外的开发脚本
完成故障转移之后可以对MySQL集群进行高可用监控
缺点:
故障简单粗暴,容易丢失事务,建议采用半同步复制方式,减少失败的概率
目前MMM社区已经缺少维护,不支持基于GTID的复制
适用场景:
读写都需要高可用的
基于日志点的复制方式

2、MHA

Master High Availability Manager and Tools for MySQL。是由日本人开发的一个基于Perl脚本写的工具。这个工具专门用于监控主库的状态,当发现master节点故障时,会提升其中拥有新数据的slave节点成为新的master节点,在此期间,MHA会通过其他从节点获取额外的信息来避免数据一致性方面的问题。MHA还提供了mater节点的在线切换功能,即按需切换master-slave节点。MHA能够在30秒内实现故障切换,并能在故障切换过程中,最大程度的保证数据一致性。在淘宝内部,也有一个相似的TMHA产品。
MHA是需要单独部署的,分为Manager节点和Node节点,两种节点。其中Manager节点一般是单独部署的一台机器。而Node节点一般是部署在每台MySQL机器上的。 Node节点得通过解析各个MySQL的日志来进行一些操作。
Manager节点会通过探测集群里的Node节点去判断各个Node所在机器上的MySQL运行是否正常,如果发现某个Master故障了,就直接把他的一个Slave提升为Master,然后让其他Slave都挂到新的Master上去,完全透明。

优点:
MHA除了支持日志点的复制还支持GTID的方式
同MMM相比,MHA会尝试从旧的Master中恢复旧的二进制日志,只是未必每次都能成功。如果希望更少的数据丢失场景,建议使用MHA架构。
缺点:
MHA需要自行开发VIP转移脚本。
MHA只监控Master的状态,未监控Slave的状态

3、MGR

MGR:MySQL Group Replication。 是MySQL官方在5.7.17版本正式推出的一种组复制机制。主要是解决传统异步复制和半同步复制的数据一致性问题。
由若干个节点共同组成一个复制组,一个事务提交后,必须经过超过半数节点的决议并通过后,才可以提交。引入组复制,主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。MGR依靠分布式一致性协议(Paxos协议的一个变体),实现了分布式下数据的最终一致性,提供了真正的数据高可用方案(方案落地后是否可靠还有待商榷)。
支持多主模式,但官方推荐单主模式:
多主模式下,客户端可以随机向MySQL节点写入数据
单主模式下,MGR集群会选出primary节点负责写请求,primary节点与其它节点都可以进行读请求处理.

优点:
基本无延迟,延迟比异步的小很多
支持多写模式,但是目前还不是很成熟
数据的强一致性,可以保证数据事务不丢失
缺点:
仅支持innodb,且每个表必须提供主键。
只能用在GTID模式下,且日志格式为row格式。
适用的业务场景:
对主从延迟比较敏感
希望对对写服务提供高可用,又不想安装第三方软件
数据强一致的场景

六、分库分表

前面我们做的一大段实验,目的是为了大家能够理解MySQL的主从集群。而主从集群的作用,在我们开发角度更大的是作为读写分离的支持,也是我们后面学习ShardingSphere的重点。我们这一部分就来介绍下分库分表。
​ 分库分表就是业务系统将数据写请求分发到master节点,而读请求分发到slave节点的一种方案,可以大大提高整个数据库集群的性能。但是要注意,分库分表的一整套逻辑全部是由客户端自行实现的。而对于MySQL集群,数据主从同步是实现读写分离的一个必要前提条件。

1、分库分表有什么用

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题,将原来独立的数据库拆分成若干数据库组成 ,将数据大表拆分成若干数据表组成,使得单一数据库、单一数据表的数据量变小,从而达到提升数据库性能的目 的。
例如:微服务架构中,每个服务都分配一个独立的数据库,这就是分库。而对一些业务日志表,按月拆分成不同的表,这就是分表。

2、分库分表的方式

分库分表包含分库和分表 两个部分,而这两个部分可以统称为数据分片,其目的都是将数据拆分成不同的存储单元。另外,从分拆的角度上,可以分为垂直分片和水平分片。
垂直分片: 按照业务来对数据进行分片,又称为纵向分片。他的核心理念就是转库专用。在拆分之前,一个数据库由多个数据表组成,每个表对应不同的业务。而拆分之后,则是按照业务将表进行归类,分布到不同的数据库或表中,从而将压力分散至不同的数据库或表。例如,下图将用户表和订单表垂直分片到不同的数据库:

垂直分片往往需要对架构和设计进行调整。通常来讲,是来不及应对业务需求快速变化的。而且,他也无法真正的解决单点数据库的性能瓶颈。垂直分片可以缓解数据量和访问量带来的问题,但无法根治。如果垂直分片之后,表中的数据量依然超过单节点所能承载的阈值,则需要水平分片来进一步处理。
水平分片:又称横向分片。相对于垂直分片,它不再将数据根据业务逻辑分类,而是通过某个字段(或某几个字段),根据某种规则将数据分散至多个库或表中,每个分片仅包含数据的一部分。例如,像下图根据主键机构分片。

常用的分片策略有:
​ 取余\取模 : 优点 均匀存放数据,缺点 扩容非常麻烦
​ 按照范围分片 : 比较好扩容, 数据分布不够均匀
​ 按照时间分片 : 比较容易将热点数据区分出来。
​ 按照枚举值分片 : 例如按地区分片
​ 按照目标字段前缀指定进行分区:自定义业务规则分片
水平分片从理论上突破了单机数据量处理的瓶颈,并且扩展相对自由,是分库分表的标准解决方案。
​ 一般来说,在系统设计阶段就应该根据业务耦合松紧来确定垂直分库,垂直分表方案,在数据量及访问压力不是特别大的情况,首先考虑缓存、读写分离、索引技术等方案。若数据量极大,且持续增长,再考虑水平分库水平分表方案

3、分库分表的缺点

虽然数据分片解决了性能、可用性以及单点备份恢复等问题,但是分布式的架构在获得收益的同时,也引入了非常多新的问题。
事务一致性问题
原本单机数据库有很好的事务机制能够帮我们保证数据一致性。但是分库分表后,由于数据分布在不同库甚至不同服务器,不可避免会带来分布式事务问题。
跨节点关联查询问题
在没有分库时,我们可以进行很容易的进行跨表的关联查询。但是在分库后,表被分散到了不同的数据库,就无法进行关联查询了。
这时就需要将关联查询拆分成多次查询,然后将获得的结果进行拼装。
跨节点分页、排序函数
跨节点多库进行查询时,limit分页、order by排序等问题,就变得比较复杂了。需要先在不同的分片节点中将数据 进行排序并返回,然后将不同分片返回的结果集进行汇总和再次排序。
这时非常容易出现内存崩溃的问题。
主键避重问题
在分库分表环境中,由于表中数据同时存在不同数据库中,主键值平时使用的自增长将无用武之地,某个分区数据 库生成的ID无法保证全局唯一。因此需要单独设计全局主键,以避免跨库主键重复问题。
公共表处理
实际的应用场景中,参数表、数据字典表等都是数据量较小,变动少,而且属于高频联合查询的依赖表。这一类表一般就需要在每个数据库中都保存一份,并且所有对公共表的操作都要分发到所有的分库去执行。
运维工作量
面对散乱的分库分表之后的数据,应用开发工程师和数据库管理员对数据库的操作都变得非常繁重。对于每一次数据读写操作,他们都需要知道要往哪个具体的数据库的分表去操作,这也是其中重要的挑战之一。

4、什么时候需要分库分表?

在阿里巴巴公布的开发手册中,建议MySQL单表记录如果达到500W这个级别,或者单表容量达到2GB,一般就建议进行分库分表。而考虑到分库分表需要对数据进行再平衡,所以如果要使用分库分表,就要在系统设计之初就详细考虑好分库分表的方案,这里要分两种情况。
​ 一般对于用户数据这一类后期增长比较缓慢的数据,一般可以按照三年左右的业务量来预估使用人数,按照标准预设好分库分表的方案。
​ 而对于业务数据这一类增长快速且稳定的数据,一般则需要按照预估量的两倍左右预设分库分表方案。并且由于分库分表的后期扩容是非常麻烦的,所以在进行分库分表时,尽量根据情况,多分一些表。最好是计算一下数据增量,永远不用增加更多的表。
​ 另外,在设计分库分表方案时,要尽量兼顾业务场景和数据分布。在支持业务场景的前提下,尽量保证数据能够分得更均匀。
​ 最后,一旦用到了分库分表,就会表现为对数据查询业务的灵活性有一定的影响,例如如果按userId进行分片,那按age来进行查询,就必然会增加很多麻烦。如果再要进行排序、分页、聚合等操作,很容易就扛不住了。这时候,都要尽量在分库分表的同时,再补充设计一个降级方案,例如将数据转存一份到ES,ES可以实现更灵活的大数据聚合查询。

5、常见的分库分表组件

由于分库分表之后,数据被分散在不同的数据库、服务器。因此,对数据的操作也就无法通过常规方式完成,并且 它还带来了一系列的问题。好在,这些问题不是所有都需要我们在应用层面上解决,市面上有很多中间件可供我们 选择,我们来了解一下它。
shardingsphere 官网地址:shardingsphere
Sharding-JDBC是当当网研发的开源分布式数据库中间件,他是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(计划中)这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和 数据库治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
这也是我们这次学习的重点。
mycat 官网地址: mycat
基于阿里开源的Cobar产品而研发,Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得MYCAT一开始就拥有一个很好的起点,站在巨人的肩膀上,我们能看到更远。业界优秀的开源项目和创新思路被广泛融入到MYCAT的基因中,使得MYCAT在很多方面都领先于目前其他一些同类的开源项目,甚至超越某些商业产品。
MyCAT虽然是从阿里的技术体系中出来的,但是跟阿里其实没什么关系。
DBLE 官网地址:DBLE
该网站包含几个重要产品。其中分布式中间件可以认为是MyCAT的一个增强版,专注于MySQL的集群化管理。另外还有数据传输组件和分布式事务框架组件可供选择。

MySql的高可用方案相关推荐

  1. Mysql之高可用方案浅析

    在工程项目中,系统应用的高可用性越来越重要,业主越来越重视.其实高可用可以分为应用层高可用和数据层高可用,数据层高可用中常见的有关系型数据库mysql的高可用.非关系型NoSQl数据库redis的高可 ...

  2. Mysql的高可用方案及主从详细配置

    1.常用的高可用MySQL解决方案: 数据库作为最基础的数据存储服务之一,在存储系统中有着非常重要的地位,因此要求其具备高可用性无可厚非.能实现不同SLA(服务水平协定)的解决方案有很多种,这些方案可 ...

  3. MySQL第七讲 MySQL的高可用方案

           MySQL服务的主从和互主以及半同步 集群,都是使用MySQL自身的功能来搭建的集群.但是 这样的集群,不具备高可用的功能.即如果是MySQL主服务挂了,从服务是没办法 自动切换成主服务 ...

  4. MySQL常见高可用方案

    MySQL成熟的高可用解决方案比较多,业界广泛运用的包括M-S,MMM,MHA,MySQL Innodb Cluster,MySQL NDB Cluster,MGR,DRDB等,下面对这些方案按照所采 ...

  5. 几种常见Mysql数据库高可用方案

    1.概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断 ...

  6. mysql的高可用方案-PXC方案(综合各方的资料)

    一.基于主从复制的高可用方案:双节点主从 + keepalived 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 一般来说,中小型规模的时候,采用这种 ...

  7. MySQL 常用高可用方案

    这一节内容来简单聊聊 MySQL 最常用的几种高可用方案. 1 主从或主主 + Keepalived 主从或主主 + Keepalived 算是历史比较悠久的 MySQL 高可用方案,常见架构如下: ...

  8. 高可用mysql笔记_MySQL笔记-高可用方案

    MySQL笔记-高可用方案 一.概述 MYSQL高可用方案有多种,本次针对其中部分方案进行实践.包括主从,双主,myql+keepalived, mysql+mycat+keepalived. 纸上得 ...

  9. mysql 双主 脑裂_MySQL高可用方案——双主

    MySQL高可用方案--双主 发布时间:2020-03-01 20:45:48 来源:51CTO 阅读:253 作者:warrent MySQL的高可用方案有很多种,双主.MHA.MMM等等,这里只是 ...

最新文章

  1. 学习编程能够从事哪些行业?
  2. 【计算机网络】计算机网络 相关概念 ( 计算机网络概念 | 计算机网络功能 | 组成 | 工作方式 | 功能组成 | 分类 )
  3. outlook从服务器中恢复已删除项目,Exchange 恢复已删除项目
  4. 2.2.1 计算机网络之传输介质(双绞线、同轴电缆、光纤、无线电缆、微波、激光、红外线)
  5. lodop打印html内容,Lodop打印控件在页面如何使用
  6. 剑指offer---用两个栈实现队列
  7. 简单介绍java Enumeration(转)
  8. 数据科学家们会被 AutoML 代替吗?
  9. 如何安装中文manpage
  10. 在ASP.NET Atlas中调用Web Service——介绍及简单应用
  11. mysql忽略大小写 chmod_Ubuntu18.04下Mysql8.0.15关闭大小写敏感
  12. python return多个值_Python函数中如何返回多个值?
  13. WiFi共享二维码自动生成
  14. spring xml解析详解
  15. Python实现商场管理系统
  16. HttpWatch工具简介及使用技巧(转)
  17. 苹果手机编辑word_苹果手机更新后卡顿,关闭这两个开关立马恢复,设置之后差点泪崩...
  18. 虚拟机安装系统的网络配置问题(Contos7版)
  19. Win11设备管理器在哪里打开?
  20. 异步调用如何使用是最好的方式?

热门文章

  1. Python 实现微信防撤回功能
  2. IDEA控制台换行方法
  3. lower_bound用法
  4. VS2015 C++编译报大量错误
  5. 基于Python会话与requests库实现河北网络学院自动化
  6. 心血管支架手术后反复低烧不退是什么原因,怎么治疗?
  7. rsync + inotify 实现实时同步
  8. 二《计算机网络》-物理层部分
  9. pv、vg、lv 创建扩展删除
  10. TestBird测试游戏《有杀气童话》强势登陆付费榜榜首