今天是感恩节，细想，我最想感恩的人是我自己。
从今以后我会好好的善待自己。同时我也明白，自己也将一如既往的支持我。
踏实积累，勇敢尝试！
你呢？最想感谢谁？也是自己吧 哈哈
===============================
2018年1月更新：曾经自己是多么自负的人啊 哈哈
orczhou
-
-
在MySQL的管理过程中，偶尔会遇到一些PC Server宕机或者重启，这时我需要在主机启动后再将MySQL服务启动。一般情况下，这项工作都是简单的。但是，当面临上百台或者更多的MySQL主机的时候，这种“偶尔”可能会很多，这种“偶尔”还会在半夜或者凌晨发生，如果每次都手动操作，这是很繁琐的。更重要的是，如果因此而打断了凌晨的美梦是不值得的。
-
本文将概述一些自己在使用中的问题（并不会给出step by step的使用介绍），以供参考，详细信息请留言或
。既然别人的轮子已经很好用了，我自己就不发明了。使用Cacti可以较为快速搭建一个MySQL性能监控平台：
-
在10月24日，Percona发布了Xtrabackup第一个RC版本0.9.5rc。
仍然是一点点的改进，这次Innobackupex增加了参数--no-lock，待备份的数据表都是InnoDB时，而且不需要二进制日志位置，可以实现全程不锁表(否则是会有短暂的锁表)。这里有更多Change log。这个RC版本中，发布了更多平台(RHEL4,5, Debian, FreeBSD, MacOS)的二进制包，免去了编译之苦。
在统计中，我们共使用了3631次备份，尚没有一次因为Xtrabackup本身的bug而备份失败。3631次中有28失败，都是因为诸如“目的地址不可写”、“磁盘分区已经满”等导致。而且也曾做过实验，在高并发写入压力下使用，Xtrabackup表现依旧正常。
在使用Xtrabackup过程中，也遇到过一些问题。
在备份同时，如果数据库写入量比较大，Xtrabackup会输出（stderr）大量的备份信息，这曾塞满了我的/tmp空间（4.6G）导致备份失败。因为希望从这些信息中获得”innobackupex: innobackup completed OK! “，所以我不得不准备更大的空间保持这些巨大的无用的日志。这个Bug已经提交。在使用--stream备份的时候，xtrabackup会把xtrabackup_logfile临时（默认的）放在/tmp，有时候会把整个/tmp塞满而导致备份失败。这个只有在使用--stream备份时会发生，可以通过参数--tmpdir指定一个临时存放的位置，避免/tmp空间不够的问题。Xtrabackup在备份5.1数据库的时候，另一个bug是innobackupex.pl脚本的问题，它会导致备份恢复后系统表中的general_log、slow_log不能使用。原因是5.1.12之后，mysql系统表中会增加的数据表general_log、slow_log使用了CVS存储引擎，每一个CVS表有.frm、.CSM、.CSV三个文件，而使用innobackupex.pl备份时，是不会备份.CSM、.CSV的文件的。不过这个Bug可以通过修改innobackupex.pl脚本的方法更正。修复方法如下：
Patch innobackupex.pl to include CSV tables, specifically line 1811 from my $wildcard = '*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,opt,par}'; to my $wildcard = '*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}';关于Xtrabackup的一个等待：在它的Wiki上介绍Innobackupex时有一个not implemented yet的参数[–incremental]，仍然not implemented。
（全文完）