购物网站模板,免费软件编程入门自学,网站布局设计软件,一站式网站开发
目录
一、实验目的与环境
二、基础环境介绍
三、搭建主从集群
1、理论基础
2、同步的原理
3、搭建主从集群
3.1 配置master主服务器
3.2 配置slave从服务
3.3 主从集群测试
3.4 集群搭建扩展#xff1a;
3.5、GTID同步集群
4、集群扩容
5、半同步复…
目录
一、实验目的与环境
二、基础环境介绍
三、搭建主从集群
1、理论基础
2、同步的原理
3、搭建主从集群
3.1 配置master主服务器
3.2 配置slave从服务
3.3 主从集群测试
3.4 集群搭建扩展
3.5、GTID同步集群
4、集群扩容
5、半同步复制
1、理解半同步复制
2、搭建半同步复制集群
6、主从架构的数据延迟问题
四、MySQL的高可用方案--了解
1、MMM
2、MHA
3、MGR
五、分库分表
1、分库分表有什么用
2、分库分表的方式
3、分库分表的缺点
4、什么时候需要分库分表
5、常见的分库分表组件 一、实验目的与环境 实验目的
MySQL是现在互联网最常用的开源数据库产品。但是我们平常开发使用大都是用的单机服务。而在实际生产中往往数据量会极为庞大并且数据的安全性要求也更高这样单机的MySQL不管是性能还是安全都是达不到要求的。所以在生产环境中MySQL必须是要搭建一套主从复制的架构同时可以基于一些工具实现高可用架构。然后在此基础上就可以基于一些中间件实现读写分离架构。最后如果数据量非常大还必须可以实现分库分表的架构。
当然MySQL的这些架构搭建还是比较复杂的通常会由专门的运维人员来搭建。所以这次实验的目的并不是要大家就学会去搭建MySQL集群而是带大家对生产环境下的MySQL架构有一定的理解能够在自己的生产项目中运用上MySQL的生产架构。
1、Linux服务器两台centos7
2、mysql版本mysql-8.0.20 说明 MySQL服务器安装方式大家可以参考官网的手册自行进行。 MySQL安装手册地址MySQL :: MySQL 8.0 Reference Manual :: 2.2 Installing MySQL on Unix/Linux Using Generic Binaries 如果在Linux上进行实验而MySQL安装实在有问题的话可以推荐大家使用宝塔面板可以省掉非常多的MySQL安装的问题。 另外对于熟悉Docker的同学可以直接用Docker来搭建更为简单高效也是未来互联网企业进行服务搭建的主流方式。大家以后学Docker的时候也可以留意下。 二、基础环境介绍
两台服务器均安装CentOS7。 1、192.168.232.128 作为mysql主节点部署 2、192.168.232.129 作为mysql从节点部署 mysql版本mysql-8.0.20
为了便于使用两个mysql服务需要打开远程登录权限开启方式需要在本机登录mysql执行以下语句。
#开启远程登录
use mysql;
update user set host% where userroot;
flush privileges;三、搭建主从集群
1、理论基础 主从架构有什么用通过搭建MySQL主从集群可以缓解MySQL的数据存储以及访问的压力。
1、数据安全
给主服务增加一个数据备份。基于这个目的可以搭建主从架构或者也可以基于主从架构搭建互主的架构。
2、读写分离
对于大部分的JAVA业务系统来说都是读多写少的读请求远远高于写请求。这时当主服务的访问压力过大时可以将数据读请求转为由从服务来分担主服务只负责数据写入的请求这样大大缓解数据库的访问压力。
要理解MySQL的主从架构只是实现读写分离的一个基础。实现读写分离还是需要一些中间件来支持比如ShardingSphere。
3、故障转移-高可用
当MySQL主服务宕机后可以由一台从服务切换成为主服务继续提供数据读写功能。
对于高可用架构主从数据的同步也只是实现故障转移的一个前提条件要实现MySQL主从切换还需要依靠一些其他的中间件来实现。比如MMM、MHA、MGR。
在一般项目中如果数据库的访问压力没有那么大那读写分离不一定是必须要做的但是主从架构和高可用架构则是必须要搭建的。
2、同步的原理 MySQL服务的主从架构一般都是通过binlog日志文件来进行的。即在主服务上打开binlog记录每一步的数据库操作然后从服务上会有一个IO线程负责跟主服务建立一个TCP连接请求主服务将binlog传输过来。这时主库上会有一个IO dump线程负责通过这个TCP连接把Binlog日志传输给从库的IO线程。接着从服务的IO线程会把读取到的binlog日志数据写入自己的relay日志文件中。然后从服务上另外一个SQL线程会读取relay日志里的内容进行操作重演达到还原数据的目的。我们通常对MySQL做的读写分离配置就必须基于主从架构来搭建。 MySQL的binlog不光可以用于主从同步还可以用于缓存数据同步等场景。 例如Canal可以模拟一个slave节点向MySQL发起binlog同步然后将数据落地到Redis、Kafka等其他组件实现数据实时流转。 搭建主从集群时有两个必要的要求
双方MySQL必须版本一致。至少需要主服务的版本低于从服务两节点间的时间需要同步。
3、搭建主从集群
3.1 配置master主服务器
首先配置主节点的mysql配置文件 /etc/my.cnf 这一步需要对master进行配置主要是需要打开binlog日志以及指定severId。我们打开MySQL主服务的my.cnf文件在文件中一行server-id以及一个关闭域名解析的配置。然后重启服务。
[mysqld]
server-id47
#开启binlog
log_binmaster-bin
log_bin-indexmaster-bin.index
skip-name-resolve
# 设置连接端口
port3306
# 设置mysql的安装目录
basedir/usr/local/mysql
# 设置mysql数据库的数据的存放目录
datadir/usr/local/mysql/mysql-files
# 允许最大连接数
max_connections200
# 允许连接失败的次数。
max_connect_errors10
# 服务端使用的字符集默认为UTF8
character-set-serverutf8
# 创建新表时将使用的默认存储引擎
default-storage-engineINNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_pluginmysql_native_password配置说明主要需要修改的是以下几个属性 server-id服务节点的唯一标识。需要给集群中的每个服务分配一个单独的ID。 log_bin打开Binlog日志记录并指定文件名。 log_bin-indexBinlog日志文件 重启MySQL服务 service mysqld restart
然后我们需要给root用户分配一个replication slave的权限。
#登录主数据库
mysql -u root -p
GRANT REPLICATION SLAVE ON *.* TO root%;
flush privileges;
#查看主节点同步状态
show master status;在实际生产环境中通常不会直接使用root用户而会创建一个拥有全部权限的用户来负责主从同步。 这个指令结果中的File和Position记录的是当前日志的binlog文件以及文件中的索引。
而后面的Binlog_Do_DB和Binlog_Ignore_DB这两个字段是表示需要记录binlog文件的库以及不需要记录binlog文件的库。目前我们没有进行配置就表示是针对全库记录日志。这两个字段如何进行配置会在后面进行介绍。 开启binlog后数据库中的所有操作都会被记录到datadir当中以一组轮询文件的方式循环记录。而指令查到的File和Position就是当前日志的文件和位置。而在后面配置从服务时就需要通过这个File和Position通知从服务从哪个地方开始记录binLog。 3.2 配置slave从服务
下一步我们来配置从服务mysqls。 我们打开mysqls的配置文件my.cnf修改配置文件
[mysqld]
#主库和从库需要不一致
server-id48
#打开MySQL中继日志
relay-log-indexslave-relay-bin.index
relay-logslave-relay-bin
#打开从服务二进制日志
log-binmysql-bin
#使得更新的数据写进二进制日志中
log-slave-updates1
# 设置3306端口
port3306
# 设置mysql的安装目录
basedir/usr/local/mysql
# 设置mysql数据库的数据的存放目录
datadir/usr/local/mysql/mysql-files
# 允许最大连接数
max_connections200
# 允许连接失败的次数。
max_connect_errors10
# 服务端使用的字符集默认为UTF8
character-set-serverutf8
# 创建新表时将使用的默认存储引擎
default-storage-engineINNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_pluginmysql_native_password配置说明主要需要关注的几个属性 server-id服务节点的唯一标识 relay-log打开从服务的relay-log日志。 log-bin打开从服务的bin-log日志记录。 然后我们启动mysqls的服务并设置他的主节点同步状态。
#登录从服务
mysql -u root -p;
#设置同步主节点
CHANGE MASTER TO
MASTER_HOST192.168.232.128,
MASTER_PORT3306,
MASTER_USERroot,
MASTER_PASSWORDroot,
MASTER_LOG_FILEmaster-bin.000004,
MASTER_LOG_POS156
GET_MASTER_PUBLIC_KEY1;
#开启slave
start slave;
#查看主从同步状态
show slave status;
或者用 show slave status \G; 这样查看比较简洁注意CHANGE MASTER指令中需要指定的MASTER_LOG_FILE和MASTER_LOG_POS必须与主服务中查到的保持一致。 并且后续如果要检查主从架构是否成功也可以通过检查主服务与从服务之间的File和Position这两个属性是否一致来确定。 我们重点关注其中红色方框的两个属性与主节点保持一致就表示这个主从同步搭建是成功的。 从这个指令的结果能够看到有很多Replicate_开头的属性这些属性指定了两个服务之间要同步哪些数据库、哪些表的配置。只是在我们这个示例中全都没有进行配置就标识是全库进行同步。后面我们会补充如何配置需要同步的库和表。 3.3 主从集群测试
测试时我们先用showdatabases查看下两个MySQL服务中的数据库情况 然后我们在主服务器上创建一个数据库
mysql create database syncdemo;
Query OK, 1 row affected (0.00 sec) 然后我们再用show databases来看下这个syncdemo的数据库是不是已经同步到了从服务。 接下来我们继续在syncdemo这个数据库中创建一个表并插入一条数据。
mysql use syncdemo;
Database changed
mysql create table demoTable(id int not null);
Query OK, 0 rows affected (0.02 sec)mysql insert into demoTable value(1);
Query OK, 1 row affected (0.01 sec) 然后我们也同样到主服务与从服务上都来查一下这个demoTable是否同步到了从服务。 从上面的实验过程看到我们在主服务中进行的数据操作就都已经同步到了从服务上。这样我们一个主从集群就搭建完成了。 另外这个主从架构是有可能失败的如果在slave从服务上查看slave状态发现Slave_SQL_Runningno就表示主从同步失败了。这有可能是因为在从数据库上进行了写操作与同步过来的SQL操作冲突了也有可能是slave从服务重启后有事务回滚了。 如果是因为slave从服务事务回滚的原因可以按照以下方式重启主从同步 mysql stop slave ;
mysql set GLOBAL SQL_SLAVE_SKIP_COUNTER1;
mysql start slave ;而另一种解决方式就是重新记录主节点的binlog文件消息 mysql stop slave ;
mysql change master to .....
mysql start slave ;但是这种方式要注意binlog的文件和位置如果修改后和之前的同步接不上那就会丢失部分数据。所以不太常用。 3.4 集群搭建扩展
在完成这个基本的MySQL主从集群后我们还可以进行后续的实验
1、全库同步与部分同步
之前提到我们目前配置的主从同步是针对全库配置的而实际环境中一般并不需要针对全库做备份而只需要对一些特别重要的库或者表来进行同步。那如何针对库和表做同步配置呢
首先在Master端在my.cnf中可以通过以下这些属性指定需要针对哪些库或者哪些表记录binlog
#需要同步的二进制数据库名
binlog-do-dbmasterdemo
#只保留7天的二进制日志以防磁盘被日志占满(可选)
expire-logs-days 7
#不备份的数据库
binlog-ignore-dbinformation_schema
binlog-ignore-dbperformation_schema
binlog-ignore-dbsys然后在Slave端在my.cnf中需要配置备份库与主服务的库的对应关系。
#如果salve库名称与master库名相同使用本配置
replicate-do-db masterdemo
#如果master库名[mastdemo]与salve库名[mastdemo01]不同使用以下配置[需要做映射]
replicate-rewrite-db masterdemo - masterdemo01
#如果不是要全部同步[默认全部同步]则指定需要同步的表
replicate-wild-do-tablemasterdemo01.t_dict
replicate-wild-do-tablemasterdemo01.t_num配置完成了之后在show master status指令中就可以看到Binlog_Do_DB和Binlog_Ignore_DB两个参数的作用了。
2、读写分离配置
我们要注意目前我们的这个MySQL主从集群是单向的也就是只能从主服务同步到从服务而从服务的数据表更是无法同步到主服务的。 所以在这种架构下为了保证数据一致通常会需要保证数据只在主服务上写而从服务只进行数据读取。这个功能就是大名鼎鼎的读写分离。但是这里要注意下mysql主从本身是无法提供读写分离的服务的需要由业务自己来实现。这也是我们后面要学的ShardingSphere的一个重要功能。 到这里可以看到在MySQL主从架构中是需要严格限制从服务的数据写入的一旦从服务有数据写入就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。 如果需要限制用户写数据我们可以在从服务中将read_only参数的值设为1( set global read_only1; )。这样就可以限制用户写入数据。但是这个属性有两个需要注意的地方 1、read_only1设置的只读模式不会影响slave同步复制的功能。 所以在MySQL slave库中设定了read_only1后通过 show slave status\G 命令查看salve状态可以看到salve仍然会读取master上的日志并且在slave库中应用日志保证主从数据库同步一致 2、read_only1设置的只读模式 限定的是普通用户进行数据修改的操作但不会限定具有super权限的用户的数据修改操作。 在MySQL中设置read_only1后普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时都会报出数据库处于只读模式不能发生数据变化的错误但具有super权限的用户例如在本地或远程通过root用户登录到数据库还是可以进行数据变化的DML操作 如果需要限定super权限的用户写数据可以设置super_read_only0。另外 如果要想连super权限用户的写操作也禁止就使用flush tables with read lock;这样设置也会阻止主从同步复制 3、其他集群方式
我们到这里搭建出了一个一主一从的MySQL主从同步集群具有了数据同步的基础功能。而在生产环境中通常会以此为基础根据业务情况以及负载情况搭建更大更复杂的集群。
例如为了进一步提高整个集群的读能力可以扩展出一主多从。而为了减轻主节点进行数据同步的压力可以继续扩展出多级从的主从集群。
为了提高整个集群的高可用能力可以扩展出多主的集群。
我们也可以扩展出互为主从的互主集群甚至是环形的主从集群实现MySQL多活部署。
搭建互主集群只需要按照上面的方式在主服务上打开一个slave进程并且指向slave节点的binlog当前文件地址和位置。 我们这里是使用的最为传统的Binlog方式搭建集群是基于日志记录点的方式来进行主从同步的。在这个实验中Executed_Grid_Set一列实际上就是另外一种搭建主从同步的方式即GTID搭建方式。GTID的本质也是基于Binlog来实现的主从同步只是他会基于一个全局的事务ID来标识同步进度。这个GTID全局事务ID是一个全局唯一、并且趋势递增的分布式ID策略。我们这里就不再去搭建了。 3.5、GTID同步集群
上面我们搭建的集群方式是基于Binlog日志记录点的方式来搭建的这也是最为传统的MySQL集群搭建方式。而在这个实验中可以看到有一个Executed_Grid_Set列暂时还没有用上。实际上这就是另外一种搭建主从同步的方式即GTID搭建方式。这种模式是从MySQL5.6版本引入的。
GTID的本质也是基于Binlog来实现主从同步只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID全局唯一并且趋势递增他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。
在基于GTID的复制中首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值然后主库会有把所有没有在从库上执行的事务发送到从库上进行执行并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次这样可以避免由于偏移量的问题造成数据不一致。
他的搭建方式跟我们上面的主从架构整体搭建方式差不多。只是需要在my.cnf中修改一些配置。
在主节点上
gtid_modeon
enforce_gtid_consistencyon
log_binon
server_id单独设置一个
binlog_formatrow 在从节点上
gtid_modeon
enforce_gtid_consistencyon
log_slave_updates1
server_id单独设置一个 然后分别重启主服务和从服务就可以开启GTID同步复制方式。
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从服务的数据同步了。
5、半同步复制
1、理解半同步复制
到现在为止我们已经可以搭建MySQL的主从集群互主集群但是我们这个集群有一个隐患就是有可能会丢数据。这是为什么呢这要从MySQL主从数据复制分析起。
MySQL主从集群默认采用的是一种异步复制的机制。主服务在执行用户提交的事务后写入binlog日志然后就给客户端返回一个成功的响应了。而binlog会由一个dump线程异步发送给Slave从服务。 由于这个发送binlog的过程是异步的。主服务在向客户端反馈执行结果时是不知道binlog是否同步成功了的。这时候如果主服务宕机了而从服务还没有备份到新执行的binlog那就有可能会丢数据。
那怎么解决这个问题呢这就要靠MySQL的半同步复制机制来保证数据安全。
半同步复制机制是一种介于异步复制和全同步复制之前的机制。主库在执行完客户端提交的事务后并不是立即返回客户端响应而是等待至少一个从库接收并写到relay log中才会返回给客户端。MySQL在等待确认时默认会等10秒如果超过10秒没有收到ack就会降级成为异步复制。 这种半同步复制相比异步复制能够有效的提高数据的安全性。但是这种安全性也不是绝对的他只保证事务提交后的binlog至少传输到了一个从库并且并不保证从库应用这个事务的binlog是成功的。另一方面半同步复制机制也会造成一定程度的延迟这个延迟时间最少是一个TCP/IP请求往返的时间。整个服务的性能是会有所下降的。而当从服务出现问题时主服务需要等待的时间就会更长要等到从服务的服务恢复或者请求超时才能给用户响应。
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.01 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, 1 warning (0.02 sec)mysql set global rpl_semi_sync_master_enabledON;
Query OK, 0 rows affected (0.00 sec)这三行指令中第一行是通过扩展库来安装半同步复制模块需要指定扩展库的文件名。 第二行查看系统全局参数rpl_semi_sync_master_timeout就是半同步复制时等待应答的最长等待时间默认是10秒可以根据情况自行调整。 第三行则是打开半同步复制的开关。 在第二行查看系统参数时最后的一个参数rpl_semi_sync_master_wait_point其实表示一种半同步复制的方式。 半同步复制有两种方式一种是我们现在看到的这种默认的AFTER_SYNC方式。这种方式下主库把日志写入binlog并且复制给从库然后开始等待从库的响应。从库返回成功后主库再提交事务接着给客户端返回一个成功响应。 而另一种方式是叫做AFTER_COMMIT方式。他不是默认的。这种方式在主库写入binlog后等待binlog复制到从库主库就提交自己的本地事务再等待从库返回给自己一个成功响应然后主库再给客户端返回响应。 然后我们登陆从服务安装smeisync_slave模块
mysql install plugin rpl_semi_sync_slave soname semisync_slave.so;
Query OK, 0 rows affected (0.01 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, 1 warning (0.01 sec)mysql set global rpl_semi_sync_slave_enabled on;
Query OK, 0 rows affected (0.00 sec)mysql show global variables like rpl_semi%;
----------------------------------------
| Variable_name | Value |
----------------------------------------
| rpl_semi_sync_slave_enabled | ON |
| rpl_semi_sync_slave_trace_level | 32 |
----------------------------------------
2 rows in set, 1 warning (0.00 sec)mysql stop slave;
Query OK, 0 rows affected (0.01 sec)mysql start slave;
Query OK, 0 rows affected (0.01 sec)slave端的安装过程基本差不多不过要注意下安装完slave端的半同步插件后需要重启下slave服务。 6、主从架构的数据延迟问题
在我们搭建的这个主从集群中有一个比较隐藏的问题就是这样的主从复制之间会有延迟。这在做了读写分离后会更容易体现出来。即数据往主服务写而读数据在从服务读。这时候这个主从复制延迟就有可能造成刚插入了数据但是查不到。当然这在我们目前的这个集群中是很难出现的但是在大型集群中会很容易出现。
出现这个问题的根本在于面向业务的主服务数据都是多线程并发写入的而从服务是单个线程慢慢拉取binlog这中间就会有个效率差。所以解决这个问题的关键是要让从服务也用多线程并行复制binlog数据。
MySQL自5.7版本后就已经支持并行复制了。可以在从服务上设置slave_parallel_workers为一个大于0的数然后把slave_parallel_type参数设置为LOGICAL_CLOCK这就可以了。
四、MySQL的高可用方案--了解
我们之前的MySQL服务集群都是使用MySQL自身的功能来搭建的集群。但是这样的集群不具备高可用的功能。即如果是MySQL主服务挂了从服务是没办法自动切换成主服务的。而如果要实现MySQL的高可用需要借助一些第三方工具来实现。
常见的MySQL集群方案有三种: MMM、MHA、MGR。这三种高可用框架都有一些共同点
对主从复制集群中的Master节点进行监控自动的对Master进行迁移通过VIP。重新配置集群中的其它slave对新的Master进行同步
1、MMM
MMM(Master-Master replication managerfor MysqlMysql主主复制管理器)是一套由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
MGRMySQL 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来进行查询就必然会增加很多麻烦。如果再要进行排序、分页、聚合等操作很容易就扛不住了。这时候都要尽量在分库分表的同时再补充设计一个降级方案例如将数据转存一份到ESES可以实现更灵活的大数据聚合查询。
5、常见的分库分表组件 由于分库分表之后数据被分散在不同的数据库、服务器。因此对数据的操作也就无法通过常规方式完成并且 它还带来了一系列的问题。好在这些问题不是所有都需要我们在应用层面上解决市面上有很多中间件可供我们 选择我们来了解一下它。
shardingsphere 官网地址概览 :: ShardingSphere
Sharding-JDBC是当当网研发的开源分布式数据库中间件他是一套开源的分布式数据库中间件解决方案组成的生态圈它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar计划中这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和 数据库治理功能可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
这也是我们这次学习的重点。
mycat 官网地址 MyCat2
基于阿里开源的Cobar产品而研发Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得MYCAT一开始就拥有一个很好的起点站在巨人的肩膀上我们能看到更远。业界优秀的开源项目和创新思路被广泛融入到MYCAT的基因中使得MYCAT在很多方面都领先于目前其他一些同类的开源项目甚至超越某些商业产品。
MyCAT虽然是从阿里的技术体系中出来的但是跟阿里其实没什么关系。
DBLE 官网地址爱可生开源社区
该网站包含几个重要产品。其中分布式中间件可以认为是MyCAT的一个增强版专注于MySQL的集群化管理。另外还有数据传输组件和分布式事务框架组件可供选择。
