binglog备份数据

最新推荐文章于 2024-05-05 16:01:57 发布
最新推荐文章于 2024-05-05 16:01:57 发布
阅读量553 收藏 1
点赞数
分类专栏： mysql 文章标签： 大数据 mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/C_LCH_2000/article/details/125839175
版权

一、开启binlog日志功能

1）编辑打开mysql配置文件/etc/mysql/my.cnf

┌──(root㉿kali)-[~]
└─# vim /etc/mysql/my.cnf

在[mysqld] 区块添加 log-bin=mysql-bin 确认是打开状态(mysql-bin 是日志的基本名或前缀名)

注意：每次服务器（数据库）重启，服务器会调用flush logs;，新创建一个binlog日志！

2）重启mysqld服务使配置生效

┌──(root㉿kali)-[~]
└─# service mysql restart

3）查看binlog日志是否开启

MariaDB [(none)]> show variables like 'log%';
+---------------------------------+---------------------------------------------------------------------------------+
| Variable_name                   | Value                                                                           |
+---------------------------------+---------------------------------------------------------------------------------+
| log_bin                         | ON

常用的binlog日志操作命令

1）查看所有binlog日志列表

MariaDB [(none)]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       351 |
| mysql-bin.000002 |       328 |
| mysql-bin.000003 |       328 |
| mysql-bin.000004 |       328 |
+------------------+-----------+

2）查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值

MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 |      328 |              |                  |
+------------------+----------+--------------+------------------+

3）flush刷新log日志，自此刻开始产生一个新编号的binlog日志文件

MariaDB [(none)]> flush logs;
Query OK, 0 rows affected (0.007 sec)

MariaDB [(none)]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       351 |
| mysql-bin.000002 |       328 |
| mysql-bin.000003 |       328 |
| mysql-bin.000004 |       375 |
| mysql-bin.000005 |       371 |
+------------------+-----------+

注意：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；

4）重置(清空)所有binlog日志

MariaDB [(none)]> reset master;
Query OK, 0 rows affected (0.009 sec)

MariaDB [(none)]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       328 |
+------------------+-----------+

二、查看binlog日志内容，常用有两种方式

1）使用mysqlbinlog自带查看命令法：

注意：

-->binlog是二进制文件，普通文件查看器cat、more、vim等都无法打开，必须使用自带的mysqlbinlog命令查看

-->binlog日志与数据库文件在同目录中

-->在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “--no-defaults”选项

“ps -ef|grep mysql”查看mysql的数据存放目录，可知是/var/lib//mysql

┌──(root㉿kali)-[~]
└─# cd /var/lib/mysql
┌──(root㉿kali)-[/var/lib/mysql]
└─# ls   
aria_log.00000001  ib_logfile0        mysql-bin.000002    oupeng
aria_log_control   ibtmp1             mysql-bin.000003    performance_schema
debian-10.5.flag   multi-master.info  mysql-bin.000004
ib_buffer_pool     mysql              mysql-bin.index
ibdata1            mysql-bin.000001   mysql_upgrade_info

使用mysqlbinlog命令查看binlog日志内容，下面截取其中的一个片段分析：

┌──(root㉿kali)-[/var/lib/mysql]
└─# mysqlbinlog mysql-bin.000004
......
# at 459
#220717 23:28:36 server id 1  end_log_pos 609 CRC32 0xb14f9973  Query   thread_id=32   exec_time=0     error_code=0

SET @@session.collation_database=DEFAULT/*!*/;
insert into changan(name,sec,age) values('zhangsan','m','20'),('小红','w','20')   #执行的sql语句
/*!*/;
# at 609
#220717 23:28:36 server id 1  end_log_pos 640 CRC32 0xcc1b628a  Xid = 190   #执行的时间
......

解释：

server id 1 ： 数据库主机的服务号，

end_log_pos 609： sql结束时的pos节点，

thread_id=32： 线程号

2）上面这种办法读取出binlog日志的全文内容比较多，不容易分辨查看到pos点信息 下面介绍一种更为方便的查询命令：

命令格式

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
#IN 'log_name' ：指定要查询的binlog文件名(不指定就是第一个binlog文件)
#FROM pos ：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
#LIMIT [offset,] ：偏移量(不指定就是0)
#row_count ：查询总条数(不指定就是所有行)
MariaDB [oupeng]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |      1274 |
| mysql-bin.000002 |       432 |
| mysql-bin.000003 |       432 |
| mysql-bin.000004 |       640 |
+------------------+-----------+
4 rows in set (0.000 sec)

MariaDB [oupeng]> show binlog events in 'mysql-bin.000004' \G;
*************************** 1. row ***************************
   Log_name: mysql-bin.000004
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 256
       Info: Server ver: 10.5.12-MariaDB-1-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000004
        Pos: 256
 Event_type: Gtid_list
  Server_id: 1
End_log_pos: 299
       Info: [0-1-4]
*************************** 3. row ***************************
   Log_name: mysql-bin.000004
        Pos: 299
 Event_type: Binlog_checkpoint
  Server_id: 1
End_log_pos: 342
       Info: mysql-bin.000003
*************************** 4. row ***************************
   Log_name: mysql-bin.000004
        Pos: 342
 Event_type: Binlog_checkpoint
  Server_id: 1
End_log_pos: 385
       Info: mysql-bin.000004
*************************** 5. row ***************************
   Log_name: mysql-bin.000004
        Pos: 385
 Event_type: Gtid
  Server_id: 1
End_log_pos: 427
       Info: BEGIN GTID 0-1-5
*************************** 6. row ***************************
   Log_name: mysql-bin.000004
        Pos: 427
 Event_type: Intvar
  Server_id: 1
End_log_pos: 459
       Info: INSERT_ID=3
*************************** 7. row ***************************
   Log_name: mysql-bin.000004
        Pos: 459
 Event_type: Query
  Server_id: 1
End_log_pos: 609
       Info: use `oupeng`; insert into changan(name,sec,age) values('zhangsan','m','20'),('小红','w','20')
*************************** 8. row ***************************
   Log_name: mysql-bin.000004
        Pos: 609
 Event_type: Xid
  Server_id: 1
End_log_pos: 640
       Info: COMMIT /* xid=190 */
8 rows in set (0.000 sec)

ERROR: No query specified

上面这条语句可以将指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos点的起始偏移，查询条数！ 如下操作示例：

a）查询第一个(最早)的binlog日志：

mysql> show binlog events\G;

b）指定查询 mysql-bin.000004这个文件：

mysql> show binlog events in 'mysql-bin.000004'\G;

c）指定查询 mysql-bin.000004这个文件，从pos点:609开始查起：

mysql> show binlog events in 'mysql-bin.000004' from 609\G;

d）指定查询 mysql-bin.000004这个文件，从pos点:609开始查起，查询10条（即10条语句

mysql> show binlog events in 'mysql-bin.000004' from 609 limit 10\G;

e）指定查询 mysql-bin.000004这个文件，从pos点:609开始查起，偏移2行（即中间跳过2个，查询10条

mysql> show binlog events in 'mysql-bin.000004' from 609 limit 2,10\G;

四、利用binlog日志恢复mysql数据

事先准备一张测试的表，oupeng库changan表

MariaDB [oupeng]> select*from changan;
+----+------------+-----+-----+
| id | name       | sec | age |
+----+------------+-----+-----+
|  1 | zhouyvlong | m   |  30 |
|  2 | wangyi     | m   |  30 |
+----+------------+-----+-----+

下面开始进行场景模拟：

1） oupeng库会在每天凌晨4点进行一次完全备份的定时计划任务，如下：

┌──(root㉿kali)-[~]
└─# crontab -l 0 4 * * * /usr/bin/mysqldump -uroot -p -B -F -R -x --master-data=2 oupeng |gzip >/opt/backup/oupeng_$(date +%F).sql.gz

这里手动执行下，将oupeng数据库备份到/opt/backup/oupeng$(date +%F).sql.gz文件中：

┌──(root㉿kali)-[/opt]
└─# mysqldump -uroot -p -B -F -R -x --master-data=2 oupeng |gzip >/opt/backup/oupeng$(date +%F).sql.gz
Enter password:
┌──(root㉿kali)-[/opt/backup]
└─# ls
oupeng2022-07-17.sql.gz

参数说明： -B：指定数据库   -F：刷新日志   -R：备份存储过程等   -x：锁表   --master-data：在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息

待到数据库备份完成，就不用担心数据丢失了，因为有完全备份数据在！！

由于上面在全备份的时候使用了-F选项，那么当数据备份操作刚开始的时候系统就会自动刷新log，这样就会自动产生 一个新的binlog日志，这个新的binlog日志就会用来记录备份之后的数据库“增删改”操作 查看一下：

MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000005 |      149 |              |                  |
+------------------+----------+--------------+------------------+

也就是说， mysql-bin.000005 是用来记录4:00之后对数据库的所有“增删改”操作。

2） 早上9点上班了，由于业务的需求会对数据库进行各种“增删改”操作。 比如：在ops库下member表内插入、修改了数据等等：

先是早上进行插入数据

MariaDB [oupeng]> insert into changan(name,sec,age) values('zhangsan','m','20'),
('小红','w','20')
MariaDB [oupeng]> select*from changan;
+----+------------+-----+-----+
| id | name       | sec | age |
+----+------------+-----+-----+
|  1 | zhouyvlong | m   |  30 |
|  2 | wangyi     | m   |  30 |
|  3 | zhangsan   | m   |  20 |
|  4 | 小红       | w   |  20 |
+----+------------+-----+-----+
4 rows in set (0.001 sec)

3） 中午又执行了修改和插入数据操作：

MariaDB [(none)]> update oupeng.changan set name='大牛' where id=1 ;
Query OK, 1 row affected (0.004 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [(none)]> insert into oupeng.changan(name,sec,age) values('小小','m',18);
Query OK, 1 row affected (0.002 sec)

MariaDB [(none)]> select*from oupeng.changan;
+----+----------+-----+-----+
| id | name     | sec | age |
+----+----------+-----+-----+
|  1 | 大牛     | m   |  30 |
|  2 | wangyi   | m   |  30 |
|  3 | zhangsan | m   |  20 |
|  4 | 小红     | w   |  20 |
|  5 | 小小     | m   |  18 |
+----+----------+-----+-----+
5 rows in set (0.000 sec)

4）在下午18:00的时候，悲剧莫名其妙的出现了！

手贱执行了drop语句，直接删除了ops库！吓尿了！要不要跑路！

MariaDB [(none)]> drop database oupeng;
Query OK, 1 row affected (0.006 sec)

5） 这种时候，一定不要慌张！！！ 先仔细查看最后一个binlog日志，并记录下关键的pos点，到底是哪个pos点的操作导致了数据库的破坏(通常在最后几步)；

先备份一下最后一个binlog日志文件：

┌──(root㉿kali)-[/home/kali2000]
└─# cd /var/lib/mysql 

┌──(root㉿kali)-[/var/lib/mysql]
└─# cp -v mysql-bin.000005 /opt/backup/
'mysql-bin.000005' -> '/opt/backup/mysql-bin.000005'                                                                              
┌──(root㉿kali)-[/var/lib/mysql]
└─# ls /opt/backup
mysql-bin.000005  oupeng2022-07-17.sql.gz

接着执行一次刷新日志索引操作，重新开始新的binlog日志记录文件。

按理说mysql-bin.000005 这个文件不会再有后续写入了，因为便于我们分析原因及查找ops节点，以后所有数据库操作都会写入到下一个日志文件。

MariaDB [(none)]> flush logs;
Query OK, 0 rows affected (0.007 sec)

MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000006 |      385 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.000 sec)

6） 读取binlog日志，分析问题。 读取binlog日志的方法上面已经说到。

方法一：使用mysqlbinlog读取binlog日志(不推荐)：

┌──(root㉿kali)-[~]
└─# cd /var/lib/mysql
                                                                                
┌──(root㉿kali)-[/var/lib/mysql]
└─# mysqlbinlog mysql-bin.000005

方法二：登录服务器，并查看(推荐此种方法)：

MariaDB [(none)]> show binlog events in 'mysql-bin.000005';
+------------------+-----+-------------------+-----------+-------------+------------------------------------------------------------------+
| Log_name         | Pos | Event_type        | Server_id | End_log_pos | Info                                                             |
+------------------+-----+-------------------+-----------+-------------+------------------------------------------------------------------+
| mysql-bin.000005 |   4 | Format_desc       |         1 |         146 | Server ver: 10.5.12-MariaDB-1-log, Binlog ver: 4                 |
| mysql-bin.000005 | 146 | Gtid_list         |         1 |         189 | [0-1-5]                                                          |
| mysql-bin.000005 | 189 | Binlog_checkpoint |         1 |         215 | mysql-bin.000005 |
| mysql-bin.000004 | 215 | Gtid              |         1 |         237 | BEGIN GTID 0-1-5                                                                              |
| mysql-bin.000004 | 237 | Intvar            |         1 |         259 | INSERT_ID=3                                                                                   |
| mysql-bin.000004 | 259 | Query             |         1 |         329 | use `oupeng`; insert into changan(name,sec,age) values('zhangsan','m','20'),('小红','w','20')   
| mysql-bin.000004 | 329 | Xid               |         1 |         352 | COMMIT /* xid=68 */                                                 |
| mysql-bin.000005 | 352 | Gtid              |         1 |         384 | BEGIN GTID 0-1-6                                                 |
| mysql-bin.000005 | 384 | Query             |         1 |         497 | update oupeng.changan set name='大牛' where id=1                 |
| mysql-bin.000005 | 497 | Xid               |         1 |         528 | COMMIT /* xid=70 */                                              |
| mysql-bin.000005 | 528 | Gtid              |         1 |         570 | BEGIN GTID 0-1-7                                                 |
| mysql-bin.000005 | 570 | Intvar            |         1 |         602 | INSERT_ID=5                                                      |
| mysql-bin.000005 | 602 | Query             |         1 |         729 | insert into oupeng.changan(name,sec,age) values('小小','m',18)   |
| mysql-bin.000005 | 729 | Xid               |         1 |         760 | COMMIT /* xid=72 */                                              |
| mysql-bin.000005 | 760 | Gtid              |         1 |         802 | GTID 0-1-8                                                       |
| mysql-bin.000005 | 802 | Query             |         1 |         891 | drop database oupeng                                             |
| mysql-bin.000005 | 891 | Rotate            |         1 |         938 | mysql-bin.000006;pos=4                                           |
+------------------+-----+-------------------+-----------+-------------+------------------------------------------------------------------+
17 rows in set (0.000 sec)

或者

MariaDB [oupeng]> show binlog events in 'mysql-bin.000005'\G;
......
......

*************************** 12. row ***************************
   Log_name: mysql-bin.000005
        Pos: 802
 Event_type: Query
  Server_id: 1
End_log_pos: 891
       Info: drop database oupeng
*************************** 13. row ***************************
   Log_name: mysql-bin.000005
        Pos: 891
 Event_type: Rotate
  Server_id: 1
End_log_pos: 938
       Info: mysql-bin.000006;pos=4
13 rows in set (0.001 sec)

通过分析，造成数据库破坏的pos点区间是介于 802--891 之间（这是按照日志区间的pos节点算的），只要恢复到802前就可。

7） 先把凌晨4点全备份的数据恢复：

┌──(root㉿kali)-[~]
└─# cd /opt/backup                     
                                                                                
┌──(root㉿kali)-[/opt/backup]
└─# ls            
mysql-bin.000005  oupeng2022-07-17.sql.gz
                                                                                
┌──(root㉿kali)-[/opt/backup]
└─# gzip -d oupeng2022-07-17.sql.gz                         
                                                                                
┌──(root㉿kali)-[/opt/backup]
└─# mysql -uroot -p -v < oupeng2022-07-17.sql
Enter password: 
--------------
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */
--------------

--------------
......
......
......
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */
--------------

这样就恢复了截至当日凌晨(4:00)前的备份数据都恢复了。

查看一下oupeng库：

MariaDB [(none)]> use oupeng;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [oupeng]> show tables;
+------------------+
| Tables_in_oupeng |
+------------------+
| changan          |
+------------------+
1 row in set (0.001 sec)

MariaDB [oupeng]> select*from changan;
+----+------------+-----+-----+
| id | name       | sec | age |
+----+------------+-----+-----+
|  1 | zhouyvlong | m   |  30 |
|  2 | wangyi     | m   |  30 |
+----+------------+-----+-----+
2 rows in set (0.001 sec)

数据库以恢复，但是这仅仅只是恢复了当天凌晨4点之前的数据，在4:00--18:00之间的数据还没有恢复回来！！ 怎么办呢？

莫慌！这可以根据前面提到的mysql-bin.000005的新binlog日志进行恢复。

8） 从binlog日志恢复数据 恢复命令的语法格式：

mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名

--------------------------------------------------------

常用参数选项解释：

--start-position=802 起始pos点

--stop-position=891 结束pos点

--start-datetime="2022-7-18 13:21:26" 起始时间点

--stop-datetime="2022-7-18 13:27:52" 结束时间点

--database=test 指定只恢复zyyshop数据库(一台主机上往往有多个数据库，只限本地log日志)

--------------------------------------------------------

不常用选项：

-u --user=name 连接到远程主机的用户名

-p --password[=name] 连接到远程主机的密码

-h --host=name 从远程主机上获取binlog日志

--read-from-remote-server 从某个MySQL服务器上读取binlog日志

--------------------------------------------------------

小结：实际是将读出的binlog日志内容，通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径；

a）完全恢复(需要手动vim编辑mysql-bin.000005，将那条drop语句剔除掉)

┌──(root㉿kali)-[/opt/backup]
└─# cp /var/lib/mysql/mysql-bin.000005 /opt/backup

┌──(root㉿kali)-[/opt/backup]
└─# mysqlbinlog /opt/backup/mysql-bin.000005 > /opt/backup/000005.sql

┌──(root㉿kali)-[/opt/backup]
└─# vim /opt/backup/000005.sql #删除里面的drop语句

┌──(root㉿kali)-[/opt/backup]
└─# mysql -uroot -p -v < /opt/backup/000005.sql

温馨提示： 在恢复全备数据之前必须将该binlog文件移出，否则恢复过程中，会继续写入语句到binlog，最终导致增量恢复数据部分变得比较混乱！

b）指定pos结束点恢复(部分恢复)：

--stop-position=352 pos结束节点（按照事务区间算，是384）

注意：

此pos结束节点介于“changan表原始数据”与更新“name='大牛'”之前的数据，这样就可以恢复到更改“name='大牛'”之前的数据了。 操作如下：

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --stop-position=352 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng
Enter password: 
--------------
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/
--------------
......
MariaDB [oupeng]> select*from changan;
+----+------------+-----+-----+
| id | name       | sec | age |
+----+------------+-----+-----+
|  1 | zhouyvlong | m   |  30 |
|  2 | wangyi     | m   |  30 |
|  3 | zhangsan   | m   |  20 |
|  4 | 小红       | w   |  20 |
+----+------------+-----+-----+
4 rows in set (0.001 sec)

恢复截止到更改“name='大牛'”之间的数据（按照事务区间算，是528）

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --stop-position=528 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng
Enter password:
MariaDB [oupeng]> select*from changan;
+----+----------+-----+-----+
| id | name     | sec | age |
+----+----------+-----+-----+
|  1 | 大牛     | m   |  30 |
|  2 | wangyi   | m   |  30 |
|  3 | zhangsan | m   |  20 |
|  4 | 小红     | w   |  20 |
+----+----------+-----+-----+
4 rows in set (0.000 sec)

c）指定pso点区间恢复(部分恢复)：

更新 name='大牛' 这条数据，日志区间是Pos[384] --> End_log_pos[497]，按事务区间是：Pos[353] --> End_log_pos[528]

插入 name='小小' 这条数据，日志区间是Pos[602] --> End_log_pos[729]，按事务区间是：Pos[528] --> End_log_pos[760]

c1）

单独恢复 name='大牛' 这步操作，可这样：

按照binlog日志区间单独恢复：

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --start-position=384 --stop-position=497 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng

按照事务区间单独恢复：

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --start-position=352 --stop-position=528 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng

c2） 单独恢复 name='小二' 这步操作，可这样：

按照binlog日志区间单独恢复：

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --start-position=602 --stop-position=729 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng

按照事务区间单独恢复：

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --start-position=528 --stop-position=760 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng

c3） 将 name='李四'、name='小二' 多步操作一起恢复，需要按事务区间，可这样：

┌──(root㉿kali)-[/opt/backup]
└─# /usr/bin/mysqlbinlog --start-position=352 --stop-position=760 --database=oupeng /var/lib/mysql/mysql-bin.000005 | /usr/bin/mysql -uroot -p -v oupeng

查看数据库：

MariaDB [oupeng]> select*from changan;
+----+----------+-----+-----+
| id | name     | sec | age |
+----+----------+-----+-----+
|  1 | 大牛     | m   |  30 |
|  2 | wangyi   | m   |  30 |
|  3 | zhangsan | m   |  20 |
|  4 | 小红     | w   |  20 |
|  5 | 小小     | m   |  18 |
+----+----------+-----+-----+
5 rows in set (0.000 sec)

至此，被删除的数据已全部恢复！！！

树迷了路
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
数据库恢复工具，解析binglog日志
03-24
binglog日志，通常指的是数据库的日志文件，记录了数据库中所有事务的详细操作，包括INSERT、UPDATE和DELETE等操作，这对于数据的备份和恢复至关重要。 首先，我们要理解数据库恢复的基本原理。在关系型数据库管理...
mysql使用binlog备份
qq_36923648的博客
02-21 3931
一、bin-log备份作用 二、开启bin-log 设置配置文件my.inf 配置文件中加入以下内容 log-bin=/var/lib/mysql/mysql-bin //开启并设置备份文件目录，以及备份命名格式 server-id=1 //集群中数据库服务器的唯一id，非集群环境可随意调写。mysql5.7以上版本需填写 其他可选配置项举例 binlog_format =mixed expire_logs_days = 10 三、使用bin-log恢复数据 查看binlog文件
MySQL数据库的备份、恢复、导出、导入（bin log和mydump）
iuu77的博客
02-26 5185
bin log不是通过回滚来恢复数据的，而是重新执行SQL语句来恢复的。1、先给数据库上锁，防止备份过程中数据库被修改。1、LOAD DATA INFILE 导入。3、数据库解锁（一定不能忘记解锁）同时生成txt文件和sql脚本。把查询内容导出内容到txt文件。3、给mysql用户赋予权限。1、先查看数据库是否可以导出。1、在shell中恢复。2、在mysql中恢复。2、重启mysql服务。
MySQL备份与恢复策略：从mysqldump到mysqlbinlog
最新发布
Dxy1239310216的博客
05-05 398
总之，MySQL的备份与恢复是数据库管理中不可或缺的一部分。通过选择适当的备份方法、制定有效的备份计划以及制定详细的恢复策略，你可以确保在发生问题时能够迅速恢复数据并减少潜在的损失。是MySQL提供的一个逻辑备份工具，它可以导出数据库或表的结构和数据到一个SQL文件中。制定一个详细的恢复计划，包括在发生故障时应采取的步骤、恢复所需的时间以及任何必要的依赖项。是两个最常用的工具。如果你有一个完整的二进制日志序列，并且知道某个时间点之前的数据是完整的，你可以使用。备份的恢复更复杂，并且需要更多的知识和经验。
mysql教程：binlog日志和数据备份
学亮编程手记
10-29 91
mysql binlog
mysql中binlog 参数设置 启用binlog 清理binlog mysqlbinlog使用 mysqldump + mysqlbinlog用于数据备份和恢复 代码实现处理binlog
热门推荐
不是一枚开发
12-01 6万+
文章目录一.二进制日志格式(Binary Logging Formats)1.1 binlog介绍1.2 启用binlog1.3 binlog几十种配置说明1.4 清理binlog日志1.5 sql命令查看配置二. mysqlbinlog使用2.1 查看binlog文件2.2 mysqldump + mysqlbinlog用于数据备份和恢复三. binlog的3种格式四. 代码实现对binlog的处理（仅提供思路） 一.二进制日志格式(Binary Logging Formats) 1.1 binlog介绍
MySQL-binlog+dump备份还原
大虾好吃吗
04-02 3106
MySQL备份一般采取全库备份加日志备份的方式，例如每天执行一次全备份，每小时执行一次二进制日志备份。这样在MySQL故障后可以使用全备份和日志备份将数据恢复到最后一个二进制日志备份前的任意位置或时间。
Mysql主从同步备份策略分享
09-11
MySQL 主从同步备份策略是指在 master 服务器和 slave 服务器之间实现数据同步的备份策略。该策略可以确保数据的一致性和可用性，提高系统的可靠性和稳定性。 在本文中，我们将介绍 MySQL 主从同步备份策略的配置...
Binlog2Hive:MySQL增量数据实时同步到HDFSHive
04-29
项目背景RDS的数据实时同步到HDFS下，并映射到Hive原理通过解析RDS的binlog将RDS的增量数据同步到HDFS下，并映射加载到Hive外部分区表由于RDS表中的第二个字段都为datetime字段，所以刚才以该字段作为Hive的分区字段...
Linux上通过binlog文件恢复mysql数据库详细步骤
09-10
- 将最新备份的数据库文件（如`Test_DB_backup.sql`）导入到新的数据目录。 - 重启MySQL服务，此时数据库处于初始备份状态。 - 通过`mysqlbinlog`命令找出丢失数据之后的binlog事件。 - 使用`mysqlbinlog --...
canal-client:canal客户端、解析binlog日志将数据从mysql过渡到rabbitmq和mongodb中
05-14
canal客户端、解析binlog日志将数据从mysql过渡到rabbitmq和mongodb中 软件架构 软件架构说明 安装教程 下载最新版本的canal服务端， 解压缩 mkdir /tmp/canal tar zxvf canal.deployer-$version.tar.gz -C /tmp/...
【一】MySQL 备份命令 和 binlog 解析命令 和 gtid 和 表复制 和 登录 和 环境变量
cpxsxn的博客
09-01 1371
备份命令：mysqldump --single-transaction --master-data=2 --hex-blob --set-gtid-purged=OFF -uinception -p -h172.25.206.228 xdbamp api > /tmp/api.sql Binlog 解析：mysqlbinlog --database archiver -vv --start-datetime='2021-09-01 12:35:00' --stop-datetime=
数据库备份与恢复（实战mysqldump+bin-log）
菜鸟的博客
10-18 1622
指定dump所有数据库。等价于使用--databases选定所有库。
MySQL中binlog备份脚本分享
supeerzdj的博客
08-17 121
关于二进制日志（binlog)的备份,可以基于flush logs方式先切换binlog，然后拷贝&压缩到到远程服务器或本地服务器的其他存储上，例如挂载的NAS存储，也可以使用mysqlbinlog实现binlog的备份，可以实现MySQL二进制日志（binlog)的本地备份或远程备份。例如，第一种方式，这种备份方式都是周期性的，如果在某个周期中，遇到一些极端情况，例如服务器宕机了，硬盘损坏了，就可能导致这段时间的binlog丢失了。参考资料中的脚本由于使用了循环操作，不适合在作业中调用。
十分钟玩转Mysql的binlog，小白也可以实现增量备份数据
麒思妙想
06-12 993
在写文章的时候，我一直在纠结，这个到底能不能算增量备份，因为使用binlog的这种方式，按照官方文档的说话，应该叫做 point-in-time ，而非正经的增量模式，但是也聊胜于无。 首先我先阐述一下，他的基本原理，就是定时制作基线，然后定时更新binlog，形成增量数据文件，然后在必要的时候进行恢复，追溯。 下面是一个简单的流程图，首先我们来创建一个表 然后，我们来创建一个基线，并且刷新binlog 现在我们来模拟一些业务操作，插入数据 好了，这一天平安过去，我们进行增备 然后，不幸的事情.
腾讯云数据库TDSQL—备份工具binlogproducter解析
少安事务所
04-30 1142
腾讯云数据库TDSQL
mysqlbinlog命令的备份与恢复
weixin_59855996的博客
03-24 333
mysql的二进制日志记录着该数据库的所有增删改的操作日志(前提是要在自己的服务器上开启binlog)，还包括 了这些操作的执行时间。为了显示这些二进制内容，我们可以使用mysqlbinlog命令来查看
mysql binlog文件如何备份_使用mysqlbinlog备份恢复二进制文件
weixin_35260153的博客
01-31 879
目录我们知道mysqlbinlog的功能可以让MySQL的二进制文件以文本格式显示输出，让文件易读。mysqlbinlog还可以结合管道符，让mysqlbinlog的输出作为mysql的输入，在恢复二进制日志时可以用到。另外，mysqlbinlog可以用来备份二进制文件。1 mysqlbinlog的备份功能mysqlbinlog可以读取二进制日志文件并将读取到的内容完全一致以二进制格式写入到新文...
MySQL——详解binglog与Redo Log以及两阶段提交
zekser的博客
03-28 1188
详细解释binlog和redo的作用和实现，以及它的区别；同时解释了两阶段提交，以及两阶段提交的必要性，没有两阶段提交的后果等
flinkcdc读取mysqlbinglog展示数据
11-02
为了使用Flink CDC读取MySQL binlog并展示数据，你需要按照以下步骤进行操作： 1. 确保你已经安装了Flink和MySQL，并且已经开启了MySQL的binlog功能。 2. 在Flink中使用Debezium库来连接MySQL数据库并读取binlog。你...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值