二进制日志配置和运维管理

Posted 2020-08-31 梦想远航

1.sync_binlog 配置的性能与安全的考量
控制二进制日志数据多久写入磁盘一次
1.安全性的考虑,
sync_binlog=0 系统默认，二进制日志并未显式地被服务器写入磁盘,可能会丢失1个或者多个事务的数据
sync_binlog=1 对于支持XA的事务引擎如innodb,不会丢失数据
2.性能的考虑
sync_binlog=0 性能不错
sync_binlog=1 性能下降,根据业务不同,可能有20%左右的性能损耗
show variables like ‘sync_binlog%‘;

mysql> show variables like ‘sync_binlog%‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 0     |
+---------------+-------+

是否把binlog的缓存刷新到磁盘
如果是1 就是在一个事务完成后把binlog的缓存刷新到磁盘

测试性能影响
sysbench --num-threads=100 --max-requests=1000 --test=oltp --db-driver=mysql --mysql-host=192.168.1.250 --mysql-user=root --mysql-password=‘‘ prepare
创建表sbtest,10000条记录写入
运行测试
sysbench --num-threads=100 --max-requests=1000 --test=oltp --db-driver=mysql --mysql-host=192.168.1.250 --mysql-user=root --mysql-password=‘‘ run

2.配置选项 binlog_cache_size=1M
事务缓存的内存大小
如果过小,事务大于缓存那部分数据会进入磁盘,造成性能下降
如果过大,服务器其它部分分配内存下降,造成性能下降
判断事务日志缓存进入磁盘是否过多过大
show global status like ‘binlog_cache%‘;
binlog_cahce_disk_use(很小或是0 )
binlog_cache_use
max_binlog_cache_size=2M
二进制日志最大的事务大小
预防大型事务可能阻塞二进制日志太长时间,导致其它事务等待二进制日志写

3.日志轮换
(1)手工轮换
flush logs
(2)自动轮换
设置 max_binlog_size 单个日志文件的最大大小
大于最大大小会产生新的日志文件
(3)mysql重启
奔溃重启 轮换

清除日志
mysql里
1.根据编号文件名
删除mysql-bin.000100 之前的日志 但不包括 mysql-bin.000100
purge binary logs to ‘mysql-bin.000100‘;
2.根据时间
purge binary logs before ‘2017-02-18‘;
删除 2017-02-18之前的日志 但不包括 2017-02-18
3.自动删除
设置过期时间
expire_logs_days=10(天)

二进制日志和数据回滚和恢复
一.PITR数据库定点即时恢复
PITR: point in time recovery 思路与步骤
step1 :恢复全备
step2 :利用二进制日志恢复至指定的时间点
操作过程
1.使用innbackupex 工具进行全备
在/home/backup/
innobackupex --defaults-file=/etc/my.cnf --user=root /home/backup

2.更新操作
update1
update2
update3
update3是操作错误的,需要恢复到update3之前
3.恢复全备
停掉mysql服务
应用日志
到 /home/backup/
innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log 2017-02-04_15-30-43/
cd /var/lib
mv mysql mysql20170204
mkdir mysql
chown -R mysql.mysql /var/lib/mysql
cd /home/backup
innobackupex --defaults-file=/etc/my.cnf --user=root --password=‘‘ --copy-back 2017-02-04_15-30-43/
出现
innobackupex: completed OK!
表示恢复成功完成

4.使用mysqlbinlog工具过滤日志,恢复至更新update3的日志位置
查看全备时的起始位置
cd 2017-02-04_15-30-43/
cat xtrabackup_binlog_info
二进制文件名 位置
cd var/log/mysql
mysqlbinlog --base64-output=‘decode-rows‘ -vvv --start-pos=107 --stop--pos=731 mysql-bin.000100 >100.sql
mysql<100.sql

误操作的恢复
在二进制日志目录下
mysqlbinlog --base64-output=‘decode-rows‘ -vvv mysql-bin.000100 >100.sql
在100.sql中查找相关的纪录(row模式下通过注释)
生产中脚本处理