Replication 其实也是通过同步 binlog 实行数据同步的，只要效率好，全备份加 Dropbox 同步 binlog 确实是个不错的方法。

两个理智的人即使争论的面红耳赤我觉得也无所谓。而且争论可以让人思考。

对于那种根本不听你在说什么，只会一句“你个SB”的人，不要说和他争论了，和他吃饭不用买单我都不愿意。

不知道 Dropbox 同步有多智能，不知道会不会出现每次都从头上传文件的情况，这样网络的开销会很大。binlog 是追加写应该不会出现每次从头传的问题。

另外 innodb 会有如 @alvin2ye 所说的情况，innodb 不是每个事务完毕都刷 buffer pool 中的脏页到数据文件的。 即使是 myisam 也会有文件系统的 cache 以及 raid 卡的 cache 等问题不会即时同步到磁盘。

所以使用定时全备份加设置好 sync_binlog 参数之后同步 binlog 是在服务器资源不是很充足的时候的一个比较靠谱的做法。

使用全备加 binlog 原因是 Dropbox 空间毕竟有限，而 binlog 一般都增长很快，所以使用这样的"增量备份"，每次全备都可以清理掉全备前面所有或者一段时间前所有的 binlog 来节省 Dropbox 空间，当然如果哟个100G的 Dropbox 空间，一点 binlog 不删对于网站型应用同步个一年半载一点问题没有。

前台页面写数据，后台管理可以看到数据，说明成功提交了(如果是 innodb 并且autocommit=0，否则更说明数据成功写入)。——未提交读以外隔离级别下。

这句更正，不同隔离级别有区别。

MySQL 的 Query Cache 很傻，只要表有任何写操作那么关于这个表的所有 Query Cache 全部失效，而开启 Query Cache 后没条查询都要先判断有没有 Cache 所以对于经常更新的表使用 Query Cache 有可能性能不升反降。

前台页面写数据，后台管理可以看到数据，说明成功提交了(如果是 innodb 并且autocommit=0，否则更说明数据成功写入)。

过早优化是万恶之源，等问题来了再解决，身轻如燕。

没有这样的说法。

http://www.v2ex.com/t/27139 相同话题，之前讨论过。

各取所需吧，@virushuo 说的应该是过滤人才和人力的方法。

晚安，世界。

@empilot 小时候不喜欢吃茼蒿和香菜，不知道什么时候开始觉得是美味。