数据库备份

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

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

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

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包的形式提供轻量级服务；