阿里云DBS备份检查binlog和server_id

本来想买个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


This entry was posted in Linux, 数据库 and tagged , , . Bookmark the permalink.
月小升QQ 2651044202, 技术交流QQ群 178491360
首发地址:月小升博客https://java-er.com/blog/mysql-binlog-server-id/
无特殊说明,文章均为月小升原创,欢迎转载,转载请注明本文地址,谢谢
您的评论是我写作的动力

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*

  

About Me

静水流深,水滴石穿