主从

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.13 数据库服务克隆应用 1.13.1 数据库克隆概念介绍 在数据库MySQL 8.0（8.0.17+）版本中，引入了数据库的克隆功能，主要是借助clone-plugin实现的，是对数据页底层克隆； 克隆的数据是InnoDB存储引擎中的物理快照信息，包括schemas, tables, tablespaces, and data dictionar y metadata； 在数据库中出现克隆功能，主要是为了满足目前云原生的技术应用场景，同时也是为了海量数据备份而诞生的； 在数据库中实现克隆功能应用有两种方式： 本地克隆（Local Cloning）： 启动克隆操作的MySQL数据库服务器实例中的数据，将会克隆到同服务器或同节点上的一个目录里； 1669564772486 远程克隆（Remote Cloning）： 默认情况下，远程克隆操作会删除接受者（recipient）数据目录中的数据，并将其替换为捐赠者（donor）的克隆数据； 也可以将数据克隆到接受者的其他目录中，以避免删除现有数据；（属于可选操作）； 主要用于实现数据远程的快速热迁移操作，在迁移过程中，除了DDL操作情况，其他操作都不会出现阻塞情况； 还可以利用远程克隆技术，实现快速构建数据库的主从架构环境，实现主从数据信息快速复制同步； 1669564937916 1.13.2 数据库克隆原理说明 在进行数据库克隆操作时，会经历几个重要的过程或步骤： 01 Page copy： 在进行数据页复制操作时，会涉及到两个操作动作： 开启redo archiving功能，从当前点开始存储新增的redo_log，这样从当前位置点开始所有的增量修改都不会丢失； 同时上一步在page track的page被发送到目标端，确保当前位置点之前所有做的变更一定发送到目标端； 关于redo archiving实际上这是官方早就存在的功能，主要用于官方的企业级备份工具，clone利用了该特性来维持记录增量产生的redo 在开始克隆前会做一次checkpoint； 对于redo archiving功能应用，会开启一个后台线程log_archiver_thread()来做日志归档; 当有新的写入时(notify_about_advanced_write_lsn)，也会通知线程去进行归档，当arch_log_sys处于活跃状态时， 线程会控制日志写入以避免未归档的日志被覆盖（log_write_wait_on_archiver）,注意如果log_write等待时间过长的话， archive任务会被中断掉； 02 Redo copy： 停止redo archiving功能，所有归档的日志被发送到目标端，这些日志包含了从page copy阶段开始到现在的所有日志； 另外可能还需要记下当前的复制点，例如：最后一个事务提交时的binlog位置点或者gtid信息，在系统页中可以找到； 03 Done： 目标端重启实例，通过crash recovery将redo log应用上去； 克隆原理过程分析参考链接：https://zhuanlan.zhihu.com/p/437760913 说明：整个克隆过程都会以事件信息记录，可以很清晰的看到克隆的流程，如果克隆过程中断，也会以追加方式进行继续克隆； 在进行克隆功能应用时，也是存在一些限制性操作的：（结合官方列出的限制） 对于MySQL 8.0.27之前版本，在进行克隆操作期间，是不允许在捐赠者和接受者上进行DDL操作，包括：truncate table操作； 对于MySQL 8.0.27之后版本，在捐赠者上默认允许并发DDL操作，对于捐赠者上并发DDL的支持由clone_block_DDL变量控制； 对于不同版本的MySQL数据库实例之间，是不能进行克隆操作的。对于捐赠者和接受者必须是确切相同数据库服务版本； 例如：你不能克隆数据在between MySQL 5.7 and MySQL 8.0, or between MySQL 8.0.19 and MySQL 8.0.20； 这个克隆功能只支持在数据库8.0.17版本或之后的版本 参考官方链接说明：https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-limitations.html ...