MySQL中的数据恢复功能相比Oracle来说还是要单薄一些,而Oracle中的数据恢复相对来说自动化的程度要高一些。不过Mysql的二进制日志提供的信息很丰富,而日志信息在Oracle中式完全屏蔽的,对于数据的恢复可能MySQL也很灵活。
【mysql】 【SQL】 【日志】 【LOG】 【DBA】 【binlog】 …
Apr
14
2015
Apr
09
2015
Mar
25
2015
Feb
26
2015
Dec
01
2014
Nov
28
2014
如果需要恢复的二进制日志较多,较复杂,强烈建议使用MySQL自身复制来恢复binlog,而不要使用mysqlbinlog。
在MySQL手册中一直是推荐使用mysqlbinlog工具来实现指定时间点的数据恢复,事实上,这是一个经常"让人郁闷"的办法。更好的办法是,使用MySQL内部复制线程中的SQL Thread来做恢复。
这个idea来自Lazydba同学;在Google稍作搜索,在Xaprb上Baron Schwartz也很早提到了使用类似的方法来恢复binlog,在 …
[获取更多]
Nov
14
2014
Oct
10
2014
Aug
31
2014
我们都知道binlog_format有三种可选配置:STATEMENT、ROW、MIXED,相应地,基于这三种模式的Replication分别称为SBR(STATEMENT BASED Replication)、RBR、MBR。 同时,我们也知道,MySQL Replication可以支持比较灵活的binlog规则,可以设置某些库、某些表记录或者忽略不记录。
通常地,我们强烈建议不要设置这些规则,默认都记录就好,在Slave上也是如此,默认所有库都进行Replicate,不要设置DO、IGNORE、REWRITE规则。 如果非要设置这些规则的话,可能会导致某些场景下或者某些特定的SQL无法被记录,就需要特别注意了。
我经过比较简单的测试,不同的binlog_format可能会导致某些SQL不被记录的情况总结如下:
[获取更多]
Aug
29
2014