标签：主库 分库 slave master 分表 线程 主从

数据库备份

单点故障：指一个系统中提供相同功能的组件只有一个，一旦组件失效，将影响整个系统功能正常的使用；

读写分离：主要是分担主库的压力，同时也可以使主库不手动建立其它索引，提高写效率；

心跳机制：定时发送一个自定义的结构体，使对方知道本机正常活着。

DML：data manipulation language 数据操纵语言 curd

DDL：data definition language 数据定义语言

所以要有备份：

1. 主备：备机只同步主机数据，不对外提供服务；主机一挂，备机切换为主机(手动或工具)；
2. 主从：从机一般用于读写分离，写到主机，读派发到从机；(主从同步机制，读写分离用什么=如何派发)
3. 主主：都是主机，麻烦，一般不用；因为数据一致性问题(两写请求分别两主机同表上，id相同会被覆盖)；

主备、主从

切换时：

人工切换

可以参考 ：主机宕机切换

从库上操作：

1. 从机IO关闭并完成中继日志操作：stop slave io_thread ，而后show processlist的状态为has read all relay log;
2. 停止从机slave服务 stop slave
3. 将从机切换为主机：reset master reset slave all

主库上操作：如果是主机宕机，重启，并：

1. change master to master_host='ip',master_port=,

   master_user='rpl',master_password='',master_log_file='mysql-bin.1',master_log_pos=120;

2. start slave;

keepalive或脚本

1. keepalive：监控集群系统中各个服务节点的状态，自动剔除故障服务器节点，需人工恢复故障节点；
2. 脚本代码代替人工切换；

主从的读写分离实现

代码封装

1. 常用datasource多数据源方式等：
2. 优点：可随业务定制，自由度高；缺点：主从切换后，需重新配置并重启，且多语言开发需要全部去实现；

中间件

官方MySQL-Proxy，360的Atlas、Mycat；

1. 优点：多语言不必重复开发； 缺点：多个系统维护，性能瓶颈；

主从复制

​ 参考：把数据从主库复制到一个或多个从库；MySQL默认位异步复制（回调）

原理

• master记录修改操作的binlog日志；
• slave在定期对master日志探测，有修改则I/O thread线程请求master二进制事件；
• master为每个I/O thread线程启动一个dump线程，用于发送二进制事件，slave中保存到本地的中继日志(Relay Log)中，并启动sql_thread线程读取Relay Log读取并分发事务，worker线程执行更新；使与主库保存一致。

从库随机读取binlog原因

1. sql_thread，只负责读取中继中日志和分发事务，更新为

主从复制延时

主备延迟就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1

1. 查看延时：show slave status的seconds_behind_master属性；
2. 计算：主库执行完Transaction并写完binlog时间T1，从库接收完到binlog时间T2，从库执行完SQL时间为T3。即T3-T1；
3. 延时原因：一，从库机器性能；二，从库机器读压力大(与其它读线程竞争资源)；三，主从网络问题；

扩展：I/O thread等线程状态详解

1. 从库的 I/O 线程连接主库是有心跳机制的，当主库超过这个心跳时间没有发送新的 event 到 slave 上时，I/O 线程就对主库发起一个心跳请求，如果请求成功就重置心跳时间，当主库有新的 event 发送到 slave 时，这个心跳时间也会进行重置。

分库分表

单表数据量过大，需要分库分表降低单次查询的数据量，以调高查询效率；

单体数据库达到性能瓶颈需要分库分表；

分表：还是在同一服务器上

1. 水平拆分：行的拆分（阿里：单表两年内超过500W条或10G者考虑分表）
   1. 自动标准：一年或一个月建一个表，如：user_2021，业务中用${tableName}传字符串即可
   2. 第二种取模：userId%5的user-？序列表；（难以再次扩展）
   3. 优点：大表变小表，表性能提高，应用代码改动少；
   4. 缺点：难保证跨片事务一致性、跨片查询性能差、数据较难维护；
2. 垂直拆分：将业务关联度低的字段分在不同表中（一般是历史遗留问题：大字段拆分出来）
   1. 优点：避免跨页(数据页)，提高写效率(内存-读写IO次数)；利于开发与维护；
   2. 缺点：还有单表数据量过大的问题；分布式事务处理更复杂；

分库：分多个服务器提供服务；

相关问题

1. 什么是分库分表？
   1. 业务的增长，使表也变多，单表数据量也曾多，访问量也增多；数据库的承载是有限的，物理扩充虽也行，但可能成本较高，也就需要考虑分库分表以解决一定的负载问题；
   2. 分库（根据业务到不同数据库），分表（分多张表）可以缓解同一库与同一表的压力，并可以横向扩展；（实际上，垂直拆分类似分库，用于业务的分多个服务器提供）
2. 优点缺点?
   1. 分库可以减少单库的压力，分表可以减少单表访问压力；但同时维护上更加麻烦；
   2. 分表又可分水平与垂直分表：水平可将大表小表化，垂直还有大表问题；可水平分表也存在事务与查询性能问题；
3. 中间件 sharding-jdbc与mycat优缺点说明？

sharding-jdbc

1. 兼容性好：适用基于java的ORM框架(JPA、Mybatis、Hibernate等)；任意第三方数据库连接池(DBCP、c3p0、Druid等)
2. 分片策略灵活：支持等号、between、in等多维度分片
3. SQL解析功能完善：支持聚合、分组、排序、limit等
4. 缺点：维护较为麻烦(代码需改造-不能跨库连接)

mycat

1. 支持MySQL集群，可以作为proxy使用
2. 自动故障切换，高可用性；支持读写分离，支持MySQL的双主多从，一主多从，数据自动分片到多个节点，高效表关联查询；部署与实施简单
3. 不支持二维路由（支持单库多表，或多库单表），自定义连接池，存在mycat自己维护连接池困难(连接池有性能瓶颈)

比较：

1. sharding-jdbc是一个jar包，mycat是一个中间件的第三方应用；
2. sharding-jdbc需要修改代码，mycat不需要修改代码；
3. 设计理念上有一定相似性：主要流程都是：sql解析->sql路由->sql改写->sql执行->结果归并；但架构设计上不同，mycat是基于proxy，复写了Mycat协议，将mycat sever伪装为mycat数据库；sharding-jdbc则是基于jdbc的扩展以提供jar包的形式提供轻量级服务；

标签：主库,分库,slave,master,分表,线程,主从
来源： https://blog.csdn.net/m0_58104617/article/details/120479733

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。