本来想买个ECS服务器来作备份机，结果发现阿里云有个数据库备份服务叫DBS，很便宜一个月30元。 买备份服务器的预算是2000一年，DBS备份只需要360一年，显然很划算。
阿里的OSS服务器也不错，很便宜，可以备份网站的其他文件
阿里云DBS备份服务的检查
月小升估计阿里云的 DBS备份和数据库主从备份原理很相似。都是在利用数据库底层的日志文件做增量备份。因为数据库主从备份也设计两个及其重要的因素
1.binlog
2.server_id
java-er.com的服务器的binlog检查和server_id检查结果
binlog模式检查
检测项：源库binlog模式检查
检测内容：检查源数据库的binlog模式是否合法
检测结果：失败
失败原因：源库binlog format 不是row
解决方案：在源库执行：set global binlog_format=ROW,然后kill源Mysql库当前的所有连接，否则连接中的session可能以非ROW模式继续写入,会导致增量数据不一致
binlog 基本认识
MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景:
其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。
二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。
binlog
1、Statement Level模式（早期默认）
简介：每一条会修改数据的sql都会记录到master的bin-log中。Slave在复制的时候sql线程会解析成和原来master端执行过的相同语句来执行。
优点：不需要记录每一行数据的变化，减少bin-log的日志量，节约IO，提高性能。因为他只记录在master上所执行语句的细节，以及执行语句时候的上下文的信息。
缺点：很多新功能的加入在复制的时候容易导致出现问题。
2、Row Level 模式：
简介:日志中会记录成每一行数据被修改的模式，然后再slave 端在对相同的数据进行修改.
优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息。仅仅只需要记录那一条记录被修改了。所以row level的日志内容会非常清楚记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特点情况下的存储过程，或function 以及triggeer的调用和触发无法被正确复制的问题.
缺点：所有执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，可能会产生大量的日志呢。
3、Mixed （前两种的混合模式）：根据执行的每一条具体的sql语句来区分对待记录日志的形式；
4、调整模式的方法：
查看当前：show variables like '$binlog_format%';
在配置文件修改：
[mysqld]
binlog_format=mixed
binlog_format=Row
binlog_format=Statement
在线修改立即生效方法：
登录mysql后：
set session binlog_format = 'statement';
set session binlog_format ='row';
set session binlog_format ='mixed';
全局修改：set global binlog_format = "ROW" ;
退出登录后查看：
show variables like "%binlog_format%";
全局修改：
set global binlog_format = "ROW" ;
set global binlog_format = 'statement';
set global binlog_format = 'mixed';
范例：
全局修改：
set global binlog_format = "ROW" ;
注意是row 模式，查看区别
刷新binlog： mysqladmin -uroot -p123456 flush-logs
查看binlog： mysqlbinlog --base64-output=decode-rows -v mysql-bin.000005
查看本地机器的server_id
show variables like '%server_id%';
检测内容
检测项：源库server_id检查
检测内容：检查源数据库是否设置server_id大于1
检测结果
检测结果：失败
失败原因： 源库serverid没有设置，增量备份不能成功拉取binlog
解决方案： 在源实例执行：set global server_id=某个不为1的数，然后重新进行预检查；同时设置my.conf中server_id=某个不为1的数
参考文章
https://www.cnblogs.com/martinzhang/p/3454358.html
http://blog.51cto.com/linuxboys/1605899