MySQL用户授权 和 bin-log日志 详解和实战

本文详细介绍了MySQL用户授权及Binlog日志的基本概念、配置与使用方法,并通过实例演示了如何利用Binlog进行数据恢复。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、平台环境

centos6.5、MySQL5.6.22。首先当然是要有自己的环境,我是在虚拟机上去模拟实验的,因为MySQL要实现主从复制,所以需要两个服务器环境,所以在虚拟机中,你可以克隆一份一模一样的服务器,如下图:

我这里的服务器里已经提前安装好MySQL了,这里我就不演示去安装环境了。这里我已经正常进入两个服务器,然后启动了MySQL。(要是这些操作过程不懂,可以留言)到此我们就把环境都准备好了。

二、MySQL用户授权

由于我演示的是主从复制技术,所以我这里只讲解给从服务器设置授权用户,也就是只授权给从服务器连接到主服务器去。这里我的主服务器的IP是192.168.197.129,从服务器的IP的192.168.197.130。

首先查看下主数据库服务器里的用户表,这里我们知道目前只有root用户,

接着我们要添加一个新用户,然后只能是从服务器去连接:

grant all privileges on *.* to kelly@192.168.197.130 identified by '123456';

这里我解释下这句命令行的意思,grant all指的是授权所有操作权限(增删改查),*.*指的是所有数据库,kelly指的是用户名,123456是密码,192.168.197.130指的是所要授权的远程IP地址。整一句的意思是,创建一个用户kelly密码为123456,然后将此用户授权给远程IP为192.168.197.130可以访问,此用户可以访问主服务器里的所有数据库。

接着我们实际操作一遍,

 

然后我们在从服务器进行连接,再查看下是否 是主服务器的数据库:

到此,我们已经完成了给从服务器授权,大家跟着上面一步步操作进行测试,我相信会成功的,若有问题可以留言。

 三、bin-log日志

bin-log日志的定义和作用我就直接百度过来了,也很好理解的。

基本定义:二进制日志,也成为二进制日志,记录对数据发生或潜在发生更改的SQL语句,并以二进制的形式保存在磁盘中;

作用:可以用来查看数据库的变更历史(具体的时间点所有的SQL操作)、数据库增量备份和恢复(增量备份和基于时间点的恢复)、MySQL的复制(主主数据库的复制、主从数据库的复制)

文件位置:默认存放位置为数据库文件所在目录下

文件的命名方式: 名称为hostname-bin.xxxxx (重启mysql一次将会自动生成一个新的binlog)

状态的查看:mysql> show variables like '%log_bin%';

以上这些都是百度复制过来的,我们看完后也很好理解了,bin-log日志也就是二进制日志,只要数据发生改变(增删改),都是记录到日志里。所以我们可以通过bin-log日志进行数据恢复。

1、开启big-log日志

打开MySQL的配置文件:/etc/my.cnf(我这里的MySQL是放在/etc下的),

在配置文件中添加此行代码: log-bin=mysql-bin,

然后重启下MySQL:service mysqld restart

进入数据库查看是否开启成功:mysql> show variables like '%log_bin%';

接着我实际演示一次:

根据介绍流程操作是成功的,大家要自己动手测试下。

2、bin-log日志的使用

首先我们来认识几个与bin-log相关的MySQL命令:

flush logs; 会多一个最新的bin-log日志

show master status; 查看最后一个bin-log日志的相关信息

reset master; 清空所有的bin-log日志

我们先看一下bin-log日志放在哪:

 

这个时候我们进入到MySQL里,查看一下最后一个bin-log日志信息

然后刷新一下bin-log日志,再查看下最后一个bin-log日志,此时已经变成了000002这个版本了,以后的增删改操作就记录在这个最新的bin-log日志里

我们可以看一下bin-log日志存放的目录,这里就多出了新版本的bin-log日志000002,以后的操作都是记录在这里面了

 

 

接着我们创建一个数据库,然后创建一个表,再插入一些记录,然后再查看下日志信息有没有变化

接着我们再看下bin-log信息,此时位置已经发生了变化,也就是说已经对刚才的操作进行了记录。

接着我们打开二进制日志,看看里面就是记录了什么,我们需要知道的是,如果用vi打开二进制日志的乱码的,所以我们需要使用下面的命令进行打开:

/usr/local/mysql/bin/mysqlbinlog --no-defaults mysql-bin.000002

我把打开的日志截图看看(截图太多了希望大家别介意,因为想让大家了解的更清楚),我用红色圈起来的都是我们需要注意的,end_log_pos大概的意思是这这个操作的最后位置在哪,例如:end_log_pos 400,在299-400之间是存了插入操作的记录的,insert into test1 values(1); 其他的能看懂就自己看,不懂看错就跳过也没事。

 

下面我们来做一个利用二进制恢复数据库数据的操作。

流程如下:

(1)先生成一个新的日志文件(000003);

(2)然后删除test1表的数据;

(3)然后利用前一个日志恢复数据(000002);

(4)最后查看是否恢复成功。

具体如下:

 

接着用mysql-bin.000002进行数据恢复:我们到数据库里查看下是否恢复成功了:

这个时候,已经证明我们使用bin-log日志进行数据恢复成功了。

在这里可能有博友就会问:“博主,你那实验在测试时是先刷新了个bin-log版本,假如我没刷新,然后删除语句就记录在了000002这个版本了,那么你怎么恢复啊?因为你使用000002进行恢复,也是会执行删除操作的记录的,这不是坑爹吗?”。

没错,假如有博友能想到这个了,那说明上面所讲的知识点基本上理解了,并有自己去思考。这里我们当然有办法在一个有删除记录的bin-log日志进行数据恢复,你有想过为啥会有end-log-pos这个位置记录吗?这就是我们解决以上问题的方法之一:定位恢复,即恢复你想恢复的数据。我打个比方,在一个bin-log日志里,insert操作的end-log-pos为250,而delete的end-log-pos为300。那么,我们可以将数据恢复到250这个位置,而之后的操作就不恢复了,这里我们先看一下mysqlbinlog的常用参数:

--stop-position = "100"    --start-position = "50" 根据开始位置或者结束位置来恢复自己想恢复的参数

--stop-date= "2016-03-02 12:00:00"    --start-date= "2016-03-02 11:55:00" 根据开始日期时间或者结束位置来恢复自己想恢复的参数

例如:

/usr/local/mysql/bin/mysqlbinlog --no-defaults mysql-bin.000001 --stop-position="450"|mysql -uroot -p

此句的意思就是将数据恢复到位置在450之前的就OK了,在450之后(假如后面还有操作记录)的就不需要进行恢复了。

下面我通过实验操作一次:

首先重置一下bin-log日志,让其恢复到初始状态

接着插入几条数据,再删除些数据

这个时候我们可以看一下mysql-bin.000001里的内容(这里我只截取一部分):

由于我们知道删除的是大于2的数据,所以知道3和4被删除了,这里我们就恢复3和4(当然,假如误删了整个表,这里就恢复到删除操作之前的就可以了)执行如下命令:

 

接着我们进入数据库查看下是否进行恢复成功:

 

到此,bin-log日志的讲解已经告一段落。

四、总结

本次博文对MySQL的用户授权 和 bin-log日志 这两个知识点进行了详细讲解和实操,对此为下一篇讲解MySQL主从复制技术做好的铺垫。希望想学到技术的朋友可以自己跟着博文动手实验一次,当然,高手可以忽略,也可以留言交流。

 转载:http://www.cnblogs.com/it-cen/p/5234345.html

<think>我们正在讨论MySQL的二进制日志Binary Log)用于数据恢复。根据引用内容,我们可以总结出以下步骤: 1. 确保MySQL已经开启了二进制日志(如果没有开启,需要修改配置文件并重启MySQL)。 2. 使用mysqlbinlog工具查看二进制日志内容,定位需要恢复的操作位置(通过时间或位置点)。 3. 使用mysqlbinlog导出特定位置或时间段的日志内容(可以输出到文件,也可以直接通过管道导入mysql执行)。 4. 执行恢复(如果导出到文件,则使用source命令或mysql命令导入;如果通过管道,则直接执行)。 具体步骤: 步骤1:检查二进制日志是否开启 - 登录MySQL,执行:`show variables like 'log_bin';`,如果Value为ON则表示开启。 步骤2:查看二进制日志文件列表 - 执行:`show binary logs;` 步骤3:查看具体的二进制日志内容,确定要恢复的位置 - 使用mysqlbinlog工具(在命令行中执行,不是在MySQL中): ```bash mysqlbinlog /var/lib/mysql/binlog.000001 ``` 如果日志文件很大,可以结合less或grep进行查找。 步骤4:根据位置点或时间点导出日志 - 按位置点导出: ```bash mysqlbinlog --start-position=107 --stop-position=2345 /var/lib/mysql/binlog.000001 > recovery.sql ``` - 按时间点导出: ```bash mysqlbinlog --start-datetime="2024-01-01 00:00:00" --stop-datetime="2024-01-02 00:00:00" /var/lib/mysql/binlog.000001 > recovery.sql ``` 步骤5:执行恢复 - 方法1:使用source命令(在MySQL命令行中): ```sql source recovery.sql; ``` - 方法2:使用mysql命令行工具: ```bash mysql -u root -p < recovery.sql ``` 注意事项: - 恢复前最好备份当前数据,以防恢复操作带来新的问题。 - 如果恢复的数据涉及多个二进制日志文件,需要按顺序导出并执行。 引用[3][4]提供了具体的操作示例。 另外,引用[5]提到了重做日志(Redo Log),但重做日志是InnoDB存储引擎层面的日志,用于保证事务的持久性崩溃恢复,而二进制日志MySQL服务器层面的,主要用于复制数据恢复。两者不同,我们这里讨论的是二进制日志。 生成相关问题: 1. 如何开启MySQL的二进制日志? 2. 二进制日志重做日志有什么区别? 3. 如何清理旧的二进制日志文件? 请根据以上步骤注意事项编写回答。</think>### MySQL 二进制日志Binary Log)数据恢复详解 Binary LogMySQL 的核心日志机制,记录所有修改数据库的操作(增删改)。通过解析日志可实现精确数据恢复,以下是完整操作流程: --- #### 一、前提条件 1. **开启 Binary Log** 在 MySQL 配置文件 `my.cnf` 中添加: ```ini [mysqld] log-bin = /var/log/mysql/mysql-bin.log # 日志路径 server-id = 1 # 主从复制需唯一ID binlog_format = ROW # 推荐ROW格式[^1] ``` ```bash sudo systemctl restart mysql # 重启生效 ``` 2. **验证日志状态** ```sql SHOW VARIABLES LIKE 'log_bin'; -- 需返回 ON SHOW MASTER STATUS; -- 查看当前日志文件及位置[^1] ``` --- #### 二、恢复数据核心步骤 ##### ▶ 场景1:按时间点恢复(误删数据) ```bash # 导出特定时间段的日志 mysqlbinlog \ --start-datetime="2024-06-01 09:00:00" \ --stop-datetime="2024-06-01 10:00:00" \ mysql-bin.000001 > recovery.sql # 执行恢复 mysql -u root -p < recovery.sql ``` ##### ▶ 场景2:按位置点恢复(精确操作) ```bash # 解析日志找到操作位置(如误删前的位置) mysqlbinlog mysql-bin.000001 | less # 导出指定位置区间(如 start-position=107, stop-position=2345) mysqlbinlog \ --start-position=107 \ --stop-position=2345 \ mysql-bin.000001 | mysql -u root -p[^4] ``` ##### ▶ 场景3:恢复单库/单表 ```bash # 通过库名过滤日志 mysqlbinlog \ --database=your_db_name \ mysql-bin.000001 | mysql -u root -p ``` --- #### 三、关键技巧与注意事项 1. **日志解析工具** ```bash mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 # 解码ROW格式日志 ``` - 输出内容包含实际执行的 SQL 语句[^3] 2. **安全恢复建议** - 恢复前备份当前数据:`mysqldump -u root -p --all-databases > full_backup.sql` - 测试环境验证恢复脚本 - 大事务操作分段恢复,避免锁表 3. **常见错误处理** - **日志文件不存在**:检查 `show binary logs;` 确认有效文件 - **权限问题**:确保 `mysqlbinlog` MySQL 用户日志读取权限 - **GTID 冲突**:添加 `--skip-gtids` 参数忽略 GTID 限制 --- #### 四、Binary Log 维护 1. **清理旧日志** ```sql PURGE BINARY LOGS BEFORE '2024-05-01'; -- 删除指定日期前的日志[^2] SET GLOBAL expire_logs_days = 7; -- 自动保留7天日志 ``` 2. **磁盘空间监控** ```sql SHOW BINARY LOGS; -- 查看日志文件大小 ``` --- #### 五、与 Redo Log 的区别[^5] | **特性** | **Binary Log** | **Redo Log** | |----------------|------------------------------------|----------------------------------| | 作用层级 | MySQL 服务层 | InnoDB 存储引擎层 | | 记录内容 | 逻辑操作(SQL 语句) | 物理页修改(数据页变化) | | 主要用途 | 数据恢复、主从复制 | 崩溃恢复(Crash Recovery) | | 文件位置 | 自定义路径(如 /var/log/mysql/) | 固定路径(ib_logfile0,1) | > 提示:数据恢复优先使用 Binary Log;系统崩溃恢复由 Redo Log 自动完成。 --- ### 相关问题 1. 如何基于 GTID 实现更安全的二进制日志恢复? 2. 主从复制中断时,如何利用 Binary Log 修复数据一致性? 3. Binary Log 的 ROW/STATEMENT/MIXED 格式对恢复有何影响? 4. 如何监控 Binary Log 的生成速率磁盘占用? [^1]: Binary logMySQL 数据库的重要日志类型,它能够记录对数据库进行的所有修改操作[^1]。 [^2]: 删除旧的 Binary Log 文件可释放磁盘空间或维护数据库[^2]。 [^3]: 通过 `mysqlbinlog` 解析日志并定位操作位置[^3]。 [^4]: 基于位置点恢复不限定于某个特定的库或表[^4]。 [^5]: Redo Log 用于在 MySQL 崩溃恢复期间纠正由不完整事务写入的数据[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值