mysql数据库可靠性分析

mysql数据库有undo空间5种mysql做可靠性分析的方案：1．MySQL Clustering(ndb-cluster stogare)简介：MySQL公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。成本：节点服务器对RAM的需求很大，与数据库大小呈线性比例；最好使用千兆以太网络；还需要使用Dolphin公司提供的昂贵的SCI卡。优点：可用于负载均衡场合；可用于高可靠性场合；高伸缩性；真正的数据库冗余；容易维护。缺点：随着数据库的变大，对RAM的需求变得更大，因此成本很高；速度：几乎 比典型的单独服务器（无千兆以太网，无SCI卡，存储引擎相关的限制少）慢10倍。应用场合：冗余，高可靠性，负载均衡2. MySQL / GFS-GNBD/ HA (Active/Passive)简介：如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？GFS/GNBD可以提供所需的共享硬盘。GFS是事务安全的文件系统。同一时刻你可以让一个MySQL使用共享数据。成本：最多n台高性能服务器的成本，其中一个激活的，其他作为备份服务器。优点：高可靠性某种程度的冗余按照高可靠性进行伸缩缺点：没有负载均衡没有保证的冗余无法对写 *** 作进行伸缩速度：单独服务器的2倍。对读 *** 作支持得较好。应用场合：需要高可靠性的、读 *** 作密集型的应用3. MySQL / DRBD / HA (Active/Passive)简介：如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？DRBD可以提供这样的共享硬盘。DRBD可以被设置成事务安全的。同一时刻你可以让一个MySQL使用共享数据。成本：最多n台高性能服务器的成本，其中一个激活的，而其他则作为备份服务器。优点：高可靠性；一定程度的冗余；以高可靠性名义来看是可伸缩的。缺点：没有负载均衡没有保证的冗余在写负载方面没有伸缩性速度：在读写方面相当于单独服务器应用场合需要高可靠性、读 *** 作密集型的应用4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)简介：考虑不同的读、写DB数据库连接的情况。可以使用一台主服务器用于写 *** 作，而采用n台从服务器用于读 *** 作。成本：最多1台高性能写服务器，n台读服务器的成本优点:读 *** 作的高可靠性；读 *** 作的负载均衡；在读 *** 作负载均衡方面是可伸缩的。缺点：无写 *** 作的高可靠性；无写 *** 作的负载均衡；在写 *** 作方面无伸缩性；速度：同单独服务器；在读 *** 作方面支持得较好应用场合读 *** 作密集型的、需要高可靠性和负载均衡的应用。5. Standalone MySQL Servers(Functionally separated) (Active)多台功能分离的单独服务器，没有高可靠性、负载均衡能力，明显缺点太多，不予考虑。

?Show

status

?一些值得监控的变量值：

?Bytes_received和Bytes_sent

?和服务器之间来往的流量。

?Com_*服务器正在执行的命令。

?Created_*在查询执行期限间创建的临时表和文件。

?Handler_*存储引擎 *** 作。

?Select_*不同类型的联接执行计划。

?Sort_*几种排序信息。

?Show

session status like ‘Select’

?Show profiles

?SET profiling=1

?Show

profiles\G

?Show profile

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

---