目录🍁binlog日志恢复🍂binlog介绍🍂Binlog的用途🍂开启binarylog功能🍂配置binlog🍁mysqldump🍂数据库的导出🍂数据库的导入🍁mysqldump+binlog 🦐博客主页：大虾好吃吗的博客 🦐MySQL专栏：MySQL专栏地址binlog日志恢复 MySQL备份一般采取全库备份加日志备份的方式，例如每天执行一次全备份，每小时执行一次二进制日志备份。这样在MySQL故障后可以使用全备份和日志备份将数据恢复到最后一个二进制日志备份前的任意位置或时间。binlog介绍 mysql的二进制日志记录着该数据库的所有增删改的操作日志(前提是
MySQL数据被误删？在开发和在生产中总会出现各种各样的失误和意味，当MySQL的数据或表被删除后不要慌，执行以下命令，查看mysql是否开启binlog，binlog会记录下数据库表结构的变更，因此强烈建议在部署MySQL的时候开启binlog.--查看是否开启binlogON为开启，OFF则为未开启showvariableslike'%log_bin%';如果忘记自己binlog文件存放在哪里可以使用以下命令去查看，也可以到自己mysqld中去查看 。showvariableslike'%datadir%'; 我们进入存储binlog的目录可能会看到多个文件，可以使用下面一行命令查看最新的
MySQL数据被误删？在开发和在生产中总会出现各种各样的失误和意味，当MySQL的数据或表被删除后不要慌，执行以下命令，查看mysql是否开启binlog，binlog会记录下数据库表结构的变更，因此强烈建议在部署MySQL的时候开启binlog.--查看是否开启binlogON为开启，OFF则为未开启showvariableslike'%log_bin%';如果忘记自己binlog文件存放在哪里可以使用以下命令去查看，也可以到自己mysqld中去查看 。showvariableslike'%datadir%'; 我们进入存储binlog的目录可能会看到多个文件，可以使用下面一行命令查看最新的
优质博文：IT-BLOG-CN一、binlogbinlog记录数据库表结构和表数据变更，比如update/delete/insert/truncate/create，它不会记录select。存储着每条变更的SQL语句和XID事务Id等等。binlog日志文件如下：[root@192.168.10.11]#mysqlbinlogmysql-binlog.0000012..........#at523#16865420:22:43serverid1end_log_pos843Querythread_id=3exec_time=0error_code=0SETTIMESTAMP=156521934/
优质博文：IT-BLOG-CN一、binlogbinlog记录数据库表结构和表数据变更，比如update/delete/insert/truncate/create，它不会记录select。存储着每条变更的SQL语句和XID事务Id等等。binlog日志文件如下：[root@192.168.10.11]#mysqlbinlogmysql-binlog.0000012..........#at523#16865420:22:43serverid1end_log_pos843Querythread_id=3exec_time=0error_code=0SETTIMESTAMP=156521934/
（以下情况仅针对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
GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。GreatSQL是MySQL的国产分支版本，使用上与MySQL一致。用一个简明、清晰的步骤来解析一下DML操作产生的binlogevent。主要是TABLE_MAP_EVENT和UPDATE_ROWS_EVENT类型的event。使用语法简单易上手的Golang来编码。数据库使用的是MySQL5.7.34版本，Golang1.15版本。获取binlogevent获取binlog一般是模拟成从库封装通讯package向主库发送binlogdump命令（COM_BINLOG_DUMP或者COM_BINLOG_DUMP_GT
GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。GreatSQL是MySQL的国产分支版本，使用上与MySQL一致。用一个简明、清晰的步骤来解析一下DML操作产生的binlogevent。主要是TABLE_MAP_EVENT和UPDATE_ROWS_EVENT类型的event。使用语法简单易上手的Golang来编码。数据库使用的是MySQL5.7.34版本，Golang1.15版本。获取binlogevent获取binlog一般是模拟成从库封装通讯package向主库发送binlogdump命令（COM_BINLOG_DUMP或者COM_BINLOG_DUMP_GT
注：文中有个易混淆的地方"事务"sql事务，即每次数据库操作生成的事务，这个事务trx_id只在undolog里存储，因为MVVC需要记录修改的事务id，生成一个事务链，同时undolog维护了此事务是否完成的状态。日志持久化事务，为了保证redolog和binlog的一致性而用的Mysql内部独立维护的2PC提交事务。这个xid只有在redolog和binlog持久化文件中存储。各日志的存储内容阅读前提：需要对mysql的数据存储结构有一定了解，即数据页的持久化和内存读取逻辑。binlog日志binlog日志存储的是对数据库实际的数据操作，可以理解为存储的所有的数据库更新sql。mysql默
