由于在本地搭建了一个数据同步的环境用到了mysql,所以用Docker的方式来搭建了一个环境,开启了mysql5.7.x的log-bin,但是一直是不生效的,给我搞了老半天才知道问题在哪里,这个问题也是有点坑的,具体看如下操作和解答。
首先在mysql的客户端连接工具界面查询log_bins时候开启:
show variables like '%log_bin%'
执行该命令可以看到log_bin这个变量是OFF,说明log-bin是关闭的,所以需要挂一个配置文件开启log-bin,然后重启mysql的容器
docker run -p 3306:3306 --name mysql_server --privileged=true -v "d:/mysql/logs":/var/log/mysql -v "d:/mysql/data":/var/lib/mysql -v "d:/mysql/conf":/etc/mysql -e MYSQL_ROOT_PASSWORD=123456 -itd mysql:5.7.16
my.cnf配置文件内容如下:
[mysqld]
# 同一局域网内注意要唯一
server-id=1
# 开启二进制日志功能 & 日志位置存放位置`/var/lib/mysql`
log-bin=mysql-bin
# binlog格式
# 1. STATEMENT:基于SQL语句的模式,binlog 数据量小,但是某些语句和函数在复制过程可能导致数据不一致甚至出错;
# 2. MIXED:混合模式,根据语句来选用是 STATEMENT 还是 ROW 模式;
# 3. ROW:基于行的模式,记录的是行的完整变化。安全,但 binlog 会比其他两种模式大很多;
binlog_format=ROW
expire_logs_days=30
# 这里还可以配置哪些库不用开启log-bin,可以配置忽略哪些库即可
经过上面的操作你以为就开启log-bin了嘛?其实是没有的
问题原因:当经过上面的步骤后,启动mysql容器后会发现如下日志:
mysqld: [Warning] World-writable config file '/etc/mysql/my.cnf' is ignored.
这段日志的意思是说,你挂载的这个配置文件的权限太高了,进入容器查看这个my.cnf的权限如下:
如上图所示:my.cnf的权限是777,权限太大了,就会被mysql容器忽略了,这种估计它认为这种是不安全的,出于安全考虑吧,这个有点坑的,问题就出在这里的,如何解决呢?进入容器/etc/mysql下修改这个挂载的my.cnf文件的权限,然后重启mysql容器:
# 修改权限命令
chmod 644 my.cnf
重启mysql容器后查看log-bin是否开启:
然后就会惊奇地发现log_bin已经变成ON了。
binlog和redolog都是Mysql里面用来记录数据库数据变更操作的日志。
其中binlog主要用来做数据备份、数据恢复和数据同步,在Mysql的主从数据同步的场景中,master节点的数据变更,会写入到binlog中,然后再把binlog中的数据通过网络传输给slave节点,实现数据同步。
而redolog,主要是在Mysql数据库事务的ACID特性里面,用来保证数据的持久化特性。
binlog和redolog的区别有很多,可以简单总结三个点
1. 使用场景不同,binlog主要用来做数据备份、数据恢复、以及主从集群的数据同步; Redo Log主要用来实现Mysql数据库的事务恢复,保证事务的ACID特性。当数据库出现崩溃的时候,Redo Log可以把未提交的事务回滚,把已提交的事务进行持久化,从而保证数据的一致性和持久性。
2. 记录的信息不同,binlog是记录数据库的逻辑变化,它提供了三种日志格式分别是statement,row以及mixed;
redo log记录的是物理变化,也就是数据页的变化结果。
3. 记录的时机不同, binlog是在执行SQL语句的时候,在主线程中生成逻辑变化写入到磁盘中,所以它是语句级别的记录方式; RedoLog是在InnoDB存储引擎层面的操作,它是在Mysql后台线程中生成并写入到磁盘中的,所以它是事务级别的记录方式,一个事务操作完成以后才会被写入到redo log中。
通过这篇文章的分享,希望能对你有所帮助,请一键三连,么么哒!