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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了二进制日志配置和运维管理，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3050字，纯文字阅读大概需要5分钟。

内容图文

在运维Mysql过程中 一些有关二进制配置的选项和应用 ，包括 sync_binlog，max_binlog_cache_size，日子轮换,日志清除,数据回滚 和恢复，误操作的恢复等

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模式下通过注释)
生产中脚本处理

内容总结

以上是互联网集市为您收集整理的二进制日志配置和运维管理全部内容，希望文章能够帮你解决二进制日志配置和运维管理所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---