云上使用MySQL，很多人会问CDB。为了更好的理解云上MySQL，本文将介绍一些重要的知识点。1.实例类型目前，云数据库MySQL支持三种架构：基础版、高可用版和单节点高IO版。基础版单节点部署，价格低廉，性价比很高。由于是单节点，无法保证数据的安全性和可用性，所以不建议在生产环境中使用。高可用版本采用一主N从的高可用模式，实时双机热备，并提供宕机自动检测和故障自动切换。主从复制方式有异步、半同步、强同步三种。高可用版本默认为一主一从异步复制模式，可通过购买升级迁移到一主二从强同步模式。单节点高IO版本部署在单个物理节点上，性价比高；底层存储采用本地NVMeSSD硬盘，提供强大的IO性能。目前应用于只读实例，帮助业务分担读压力，适合各行业需要读写分离的应用。2、数据库实例的异步复制方式。应用程序发起数据更新（包括insert、update、delete等）请求，Master执行更新操作后立即返回响应给应用程序，然后Master将数据复制给Slave。在数据更新过程中，Master不需要等待Slave的响应，所以异步复制的数据库实例通常具有更高的性能，Slave不可用不影响Master对外提供的服务。但是由于数据不是实时同步到Slave，在Slave延迟时Master失效，小概率会造成数据不一致。腾讯云数据库MySQL异步复制采用一主一从架构。半同步复制应用发起数据更新（包括insert、update、delete操作）请求，Master执行更新操作后立即将数据复制给Slave，Slave收到数据并写入后返回给Master向relaylog（不需要执行）成功信息，Master收到Slave的成功信息后，必须返回一个响应给应用程序。只有当数据复制异常时（slave节点不可用或数据复制使用的网络异常），Master才会暂停（MySQL默认为10秒左右）响应申请，将复制方式降为异步复制。当数据复制恢复正常后，将恢复为半同步复制。腾讯云数据库MySQL半同步复制采用一主一从架构。强同步复制应用发起数据更新（包括insert、update、delete操作）请求，Master执行更新操作后立即将数据复制给Slave，Slave收到数据后向Master返回成功信息，执行它。在从Slave收到成功消息后，向应用程序返回一个响应。因为Master是同步复制数据给Slave的，所以Master的每一次更新操作都需要保证Slave也执行成功。因此，强同步复制可以最大限度地保证主从数据的一致性。但是由于每个Master的更新请求都强烈依赖于Slave的返回，如果只有一个Slave，它的不可用会极大的影响Master上的操作。腾讯云数据库MySQL强同步复制采用主双从架构，只需要其中一个从机执行成功即可返回。这样就避免了单个slave不可用影响master上运行的问题，提高了强同步复制集群的可用性。3、高可用的实现原理目前使用最多的是一主从架构的高可用版本。一般情况下，客户通过VIP:Port链接到主库，从库通过binlog与主库同步。当数据库所在物理机出现硬件故障时，云上MySQL如何保证高可用？(1)master所在物理机故障：正常情况下，client通过VIP:Port连接master库，slave库通过binlog与master同步。下图第1步，当主库所在宿主机异常宕机时，客户端的连接会切换到从库（客户端断线重连几乎不受影响），从库此时可以读写。主库出现故障后，云平台会自动生成一个新的主从高可用实例，将最后一天的冷备导入新的实例对，并同步当前旧从库的binlog。下图第2步binlog增量同步完成后，旧的从库会同步到新的实例对，直到维护时间内再次进行主备切换。切换过程中会有秒级闪现，业务重连闪现可以忽略。破碎的。此时客户端直接通过VIP+Port连接到新建的实例对上。旧实例被删除。详细步骤如下图所示。Step3MySQL主库故障切换示意图▲（2）从库所在物理机发生故障。机器出现异常后，云平台会自动启动重建从库的流程，在健康的物理机上新建一个从库，导入冷备数据并与主库同步。同步完成后，数据库将恢复主从高可用状态。4.实例升级数据库升级不仅包括数据库版本升级，还包括硬件升级。当然硬件降级的具体原理是一样的。控制台发起实例升级任务后，云平台会自动新建一个需要调整配置的实例对。先将最新的备份导出到新建的实例对，再与主实例进行binlog同步。下图步骤1完成主实例和新建实例对的同步后，用户可以选择立即切换或在维护期间切换。整个切换过程可以在几秒钟内完成。完成后，客户端连接数据库请求会转到目标实例对，源实例对会自动回收。Step2如下图从上面的步骤我们可以看出，在升级实例的时候，完全不会影响数据库的正常使用。升级花费的时间主要是导入冷备和追binlog这两个步骤，而这两个步骤所需要的时间取决于客户数据的大小和生成的binlog的大小。一般冷备份导入速度为50G/h（理论值仅供参考）。5.binlog介绍binlog日志用于记录所有改变数据的语句，俗称二进制日志，主要用于复制和时间点恢复。主从复制也依赖于binlog。类似于Oracle的archivelog和Mongodb的oplog，所有与写入相关或可能相关的语句都会记录在binlog文件中。云上MySQL数据库的binlog文件每隔1G自动生成一次（新买的实例也可能256M切一次），除非进行了flushlogs操作。MySQL的binlog默认保存5天，所以如果一个文件需要回滚，只能恢复到5天内的任意时间点。另外，如果需要在本地解析控制台下载的binlog日志，客户端的MySQL版本需要和CDBforMySQL的版本保持一致。否则会解析出乱码。推荐使用3.4或以上版本的mysqlbinlog6。回滚介绍文件是通过冷备份和binlog将数据库恢复到之前某个时间点的操作。CDB回滚分为正常回滚、快速回滚和快速回滚。普通回滚：导入实例的全量备份，然后回滚选中的库和表。这种回滚方式是无限制的，但是回滚速度慢，回滚快：只导入所选库级别的备份和binlog。如果有跨库操作，关联库没有同时选中，回滚失败，文件快速返回。文件：只导入所选表级别的备份和binlog。如果有跨表操作，并且没有同时选中关联的表，会回滚失败。在快速模式下，请手动选择需要回滚的表。如果表已经被删除，客户需要自己创建表并进行回滚操作。7.慢查询慢查询是执行数据库查询时消耗时间比较多的SQL语句。MySQLCPU使用率高的原因，大部分都与低效的SQL有关。大部分问题都可以通过优化低效的SQL基本解决。MySQL慢查询时间默认值为10s。遇到性能问题，如果没有慢查询，建议将参数调整为1s，然后在业务周期中观察慢查询，再对慢查询进行优化。如果全表扫描次数较多，可以开启log_queries_not_using_indexes参数。这时，不使用索引的全表扫描也可以记录在慢查询中。不建议一直打开这个参数，对数据库的磁盘影响很大。8.MySQL空间用户使用查询语句获取的MySQL空间与在控制台看到的已用空间有较大差异。为什么？由于MySQL的空洞效应，导致使用过程中部分碎片没有正常释放。因此，查询语句检测到的空间远小于控制台统计的实际使用空间。这部分是零散的，需要在夜深人静的时候彻底解决。执行优化表。
