（以下情况仅针对StoneDB1.0版本不支持的部分DML和DDL操作，StoneDB2.0及以上版本将无需此类操作）主从复制中，主库的任何更新都会同步到从库，如果从库不想重做主库的某个更新动作，可以使用以下两种方法进行规避。当然，最终带来的影响是主从环境数据不一致的问题。以下的测试环境中，主库是InnoDB，从库是StoneDB，在主库做从库不支持的DML或者DDL。从库执行GTID的空事务###主库mysql>showcreatetablettt\G***************************1.row***************************Table:tttCre

（以下情况仅针对StoneDB1.0版本不支持的部分DML和DDL操作，StoneDB2.0及以上版本将无需此类操作）主从复制中，主库的任何更新都会同步到从库，如果从库不想重做主库的某个更新动作，可以使用以下两种方法进行规避。当然，最终带来的影响是主从环境数据不一致的问题。以下的测试环境中，主库是InnoDB，从库是StoneDB，在主库做从库不支持的DML或者DDL。从库执行GTID的空事务###主库mysql>showcreatetablettt\G***************************1.row***************************Table:tttCre

搭建从库，本质上需要的只是一个一致性备份集及这个备份集对应的位置点信息。之前介绍的几个备份工具（ MySQL中如何选择合适的备份策略和备份工具 ）均可满足。这里，我们重点看看如何基于XtraBackup搭建从库。整个过程其实比较简单，无非是备份还原。唯一需要注意的是建立复制时位置点的选择，包括：在基于位置点的复制中，CHANGEMASTERTO语句中MASTER_LOG_FILE和MASTER_LOG_POS的选择。在GTID复制中，在执行CHANGEMASTERTO命令之前，必须首先设置GTID_PURGED。尤其是在MySQL8.0中，得益于performance_schema.log_s

搭建从库，本质上需要的只是一个一致性备份集及这个备份集对应的位置点信息。之前介绍的几个备份工具（ MySQL中如何选择合适的备份策略和备份工具 ）均可满足。这里，我们重点看看如何基于XtraBackup搭建从库。整个过程其实比较简单，无非是备份还原。唯一需要注意的是建立复制时位置点的选择，包括：在基于位置点的复制中，CHANGEMASTERTO语句中MASTER_LOG_FILE和MASTER_LOG_POS的选择。在GTID复制中，在执行CHANGEMASTERTO命令之前，必须首先设置GTID_PURGED。尤其是在MySQL8.0中，得益于performance_schema.log_s

文章来自：Mysql主从库不同步1236错误：couldnotfindfirstlogfilenameinbinary....问题分析：主库执行命令，确认日志文件和位置；mysql>showmasterstatus;+------------------+----------+--------------+------------------------------+-------------------+|File|Position|Binlog_Do_DB|Binlog_Ignore_DB|Executed_Gtid_Set|+------------------+----------+-

文章来自：Mysql主从库不同步1236错误：couldnotfindfirstlogfilenameinbinary....问题分析：主库执行命令，确认日志文件和位置；mysql>showmasterstatus;+------------------+----------+--------------+------------------------------+-------------------+|File|Position|Binlog_Do_DB|Binlog_Ignore_DB|Executed_Gtid_Set|+------------------+----------+-