Mysql备份和恢复

最新推荐文章于 2023-12-19 22:09:12 发布
最新推荐文章于 2023-12-19 22:09:12 发布
阅读量395 收藏 1
点赞数 1
分类专栏： MYSQL
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaoxiamiqianqian/article/details/115360894
版权

MySQL binlog 时间点恢复 mysqlbinlog 数据恢复
关键词由CSDN通过智能技术生成

Mysql参考手册地址:https://dev.mysql.com/doc/refman/8.0/en/backup-and-recovery.html

官网中的例子:如下↓↓↓↓↓↓↓↓↓↓

               例如，假设在2020年3月11日20:06:00左右执行了一条删除表的SQL语句。您可以执行时间点恢复，以将服务器恢复到表删除之前的状态。这些是实现该目标的一些示例步骤：

  1. 恢复在感兴趣的时间点之前创建的最后一个完整备份（在我们的示例中，将其命名为 ，即2020年3月11日的20:06:00）。完成后，记下您已还原服务器以供以后使用的二进制日志位置，然后重新启动服务器。

    笔记

    虽然还原和服务器重新启动后，InnoDB还会显示恢复的最后一个二进制日志位置，但这不是获取还原结束日志位置的可靠方法，因为可能发生了DDL事件和非InnoDB更改在显示位置反映的时间之后。您的备份和还原工具应为您提供恢复的最后一个二进制日志位置：例如，如果您使用的是mysqlbinlog 对于该任务，请检查二进制日志重播的停止位置；如果使用MySQL Enterprise Backup，则最后一个二进制日志位置已保存在备份中。请参阅 时间点恢复。

  2. 查找与要还原数据库的时间点相对应的精确二进制日志事件位置。在我们的示例中，假设我们知道删除表的大致时间（），我们可以通过使用mysqlbinlog实用工具检查该时间前后的日志内容来找到日志位置。使用和 选项在周围指定较短的时间 ，然后在输出中查找事件。例如： --start-datetime and --stop-datetime

    shell> mysqlbinlog --start-datetime="2020-03-11 20:05:00" \
                   --stop-datetime="2020-03-11 20:08:00" --verbose \
         /var/lib/mysql/bin.123456 | grep -C 15 "DROP TABLE"
 
/*!80014 SET @@session.original_server_version=80019*//*!*/;
/*!80014 SET @@session.immediate_server_version=80019*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 232
#200311 20:06:20 server id 1  end_log_pos 355 CRC32 0x2fc1e5ea 	Query	thread_id=16	exec_time=0	error_code=0
SET TIMESTAMP=1583971580/*!*/;
SET @@session.pseudo_thread_id=16/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
DROP TABLE `pets`.`cats` /* generated by server */
/*!*/;
# at 355
#200311 20:07:48 server id 1  end_log_pos 434 CRC32 0x123d65df 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=no	original_committed_timestamp=1583971668462467	immediate_commit_timestamp=1583971668462467	transaction_length=473
# original_commit_timestamp=1583971668462467 (2020-03-11 20:07:48.462467 EDT)
# immediate_commit_timestamp=1583971668462467 (2020-03-11 20:07:48.462467 EDT)
/*!80001 SET @@session.original_commit_timestamp=1583971668462467*//*!*/;
/*!80014 SET @@session.original_server_version=80019*//*!*/;
/*!80014 SET @@session.immediate_server_version=80019*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 434
#200311 20:07:48 server id 1  end_log_pos 828 CRC32 0x57fac9ac 	Query	thread_id=16	exec_time=0	error_code=0	Xid = 217
use `pets`/*!*/;
SET TIMESTAMP=1583971668/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
CREATE TABLE dogs

    从mysqlbinlog的输出中，DROP TABLE `pets`.`cats`可以在该行# at 232和之间的二进制日志段中找到该 语句 # at 355，这意味着该语句发生 在日志位置232之后，并且日志位于该DROP TABLE 语句之后的位置355 。

    笔记

    仅使用 --start-datetime和 --stop-datetime 选项来帮助您找到感兴趣的实际事件位置。不建议使用两个选项来指定要应用的二进制日志段的范围：使用这些选项时，丢失二进制日志事件的风险更高。使用 --start-position和 --stop-position 代替。

  3. 将事件以二进制日志文件的形式应用于服务器，从您在步骤1中找到的日志位置开始（假设为155），结束于您感兴趣的时间点之前在步骤2中找到的位置（这是232）：

    shell> mysqlbinlog --start-position=155 --stop-position=232 /var/lib/mysql/bin.123456 \
         | mysql -u root -p

    该命令从起始位置恢复到停止位置之前的所有事务。因为mysqlbinlog的输出SET TIMESTAMP在记录每个SQL语句之前都包含 语句，所以恢复的数据和相关的MySQL日志反映了执行事务的原始时间。

    现在，您的数据库已还原到感兴趣的时间点，即在删除表之前。 tppets.cats

  4. 除了已完成的时间点恢复之外，如果您还想在感兴趣的时间点之后重新执行所有语句 ，请再次使用mysqlbinlog将所有事件应用于服务器。我们在第2步中注意到，在要跳过的语句之后，日志位于位置355；否则，日志将移至位置355。我们可以将其用于该 选项，以便包括该头寸之后的所有语句： tp--start-position

    shell> mysqlbinlog --start-position=355 /var/lib/mysql/bin.123456 \
         | mysql -u root -p

    您的数据库已还原到二进制日志文件中记录的最新语句，但是跳过了所选事件。

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

mysql8版本 ,已开启log_bin, 在D:\software\mysql\mysql-8.0.22-winx64\bin> 下操作

 

 

1. 进入mysql安装路径:D:\software\mysql\mysql-8.0.22-winx64\data 目录下,你会看到很多命名类似binlog.000001 的文件,其中记录着sql操作信息.

2.查看data:执行mysqladmin -u root -p flush-logs 刷新日志文件,此时为0037

3.接下来,我使用 mysqldump 做一次完整备份:备份backup_test数据库下table_1表

mysqldump -u root -p backup_test table_1> D:\software\mysql\backup\table_3.sql

备份会生成sql文件,如下:记录着mysql等相关信息...

-- MySQL dump 10.13  Distrib 8.0.22, for Win64 (x86_64)
--
-- Host: localhost    Database: backup_test
-- ------------------------------------------------------
-- Server version	8.0.22

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!50503 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `table_1`
--

DROP TABLE IF EXISTS `table_1`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `table_1` (
  `id` int NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `table_1`
--

LOCK TABLES `table_1` WRITE;
/*!40000 ALTER TABLE `table_1` DISABLE KEYS */;
INSERT INTO `table_1` VALUES (1,'22'),(4,'44'),(5,'55'),(6,'66'),(7,'77'),(8,'88'),(9,'99'),(10,'10'),(11,'11'),(12,'12');
/*!40000 ALTER TABLE `table_1` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2021-03-31 21:30:58

 

 

4.对table_3进行更新操作...

    1.新增 13 13

    2.删除 11 11

    3.修改12 222

5. mysqladmin -u root -p flush-logs刷新日志,会出现0038 ,0037被保存

 

6.使用下面命令查看binlog 0037, --verbose参数可以查看到sql语句

mysqlbinlog D:\software\mysql\mysql-8.0.22-winx64\data\binlog.000037 --verbose

 

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#210331 21:26:38 server id 1  end_log_pos 125 CRC32 0xdac5e173  Start: binlog v 4, server v 8.0.22 created 210331 21:26:38
BINLOG '
jnhkYA8BAAAAeQAAAH0AAAAAAAQAOC4wLjIyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEwANAAgAAAAABAAEAAAAYQAEGggAAAAICAgCAAAACgoKKioAEjQA
CigBc+HF2g==
'/*!*/;
# at 125
#210331 21:26:38 server id 1  end_log_pos 156 CRC32 0xf4925165  Previous-GTIDs
# [empty]
# at 156
#210331 21:33:15 server id 1  end_log_pos 235 CRC32 0x4a4a685f  Anonymous_GTID  last_committed=0        sequence_number=1       rbr_only=yes    original_committed_timestamp=1617197595184185   immediate_commit_timestamp=1617197595184185
        transaction_length=302
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1617197595184185 (2021-03-31 21:33:15.184185 中国标准时间)
# immediate_commit_timestamp=1617197595184185 (2021-03-31 21:33:15.184185 中国标准时间)
/*!80001 SET @@session.original_commit_timestamp=1617197595184185*//*!*/;
/*!80014 SET @@session.original_server_version=80022*//*!*/;
/*!80014 SET @@session.immediate_server_version=80022*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 235
#210331 21:33:15 server id 1  end_log_pos 317 CRC32 0x1e697cd7  Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1617197595/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 317
#210331 21:33:15 server id 1  end_log_pos 383 CRC32 0x8b83eb60  Table_map: `backup_test`.`table_1` mapped to number 93
# at 383
#210331 21:33:15 server id 1  end_log_pos 427 CRC32 0xc396eed9  Write_rows: table id 93 flags: STMT_END_F

BINLOG '
G3pkYBMBAAAAQgAAAH8BAAAAAF0AAAAAAAEAC2JhY2t1cF90ZXN0AAd0YWJsZV8xAAIDDwL9AgIB
AQACASFg64OL
G3pkYB4BAAAALAAAAKsBAAAAAF0AAAAAAAEAAgAC/wANAAAAAgAxM9nulsM=
'/*!*/;
### INSERT INTO `backup_test`.`table_1`
### SET
###   @1=13
###   @2='13'
# at 427
#210331 21:33:15 server id 1  end_log_pos 458 CRC32 0xa2b98fd4  Xid = 85
COMMIT/*!*/;
# at 458
#210331 21:33:22 server id 1  end_log_pos 537 CRC32 0xcab0df75  Anonymous_GTID  last_committed=1        sequence_number=2       rbr_only=yes    original_committed_timestamp=1617197602429942   immediate_commit_timestamp=1617197602429942
        transaction_length=302
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1617197602429942 (2021-03-31 21:33:22.429942 中国标准时间)
# immediate_commit_timestamp=1617197602429942 (2021-03-31 21:33:22.429942 中国标准时间)
/*!80001 SET @@session.original_commit_timestamp=1617197602429942*//*!*/;
/*!80014 SET @@session.original_server_version=80022*//*!*/;
/*!80014 SET @@session.immediate_server_version=80022*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 537
#210331 21:33:22 server id 1  end_log_pos 619 CRC32 0x1f07a544  Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1617197602/*!*/;
BEGIN
/*!*/;
# at 619
#210331 21:33:22 server id 1  end_log_pos 685 CRC32 0x92da4a60  Table_map: `backup_test`.`table_1` mapped to number 93
# at 685
#210331 21:33:22 server id 1  end_log_pos 729 CRC32 0xd63bfc6e  Delete_rows: table id 93 flags: STMT_END_F

BINLOG '
InpkYBMBAAAAQgAAAK0CAAAAAF0AAAAAAAEAC2JhY2t1cF90ZXN0AAd0YWJsZV8xAAIDDwL9AgIB
AQACASFgStqS
InpkYCABAAAALAAAANkCAAAAAF0AAAAAAAEAAgAC/wALAAAAAgAxMW78O9Y=
'/*!*/;
### DELETE FROM `backup_test`.`table_1`
### WHERE
###   @1=11
###   @2='11'
# at 729
#210331 21:33:22 server id 1  end_log_pos 760 CRC32 0x805d46e6  Xid = 88
COMMIT/*!*/;
# at 760
#210331 21:33:28 server id 1  end_log_pos 839 CRC32 0x7556a37c  Anonymous_GTID  last_committed=2        sequence_number=3       rbr_only=yes    original_committed_timestamp=1617197608416725   immediate_commit_timestamp=1617197608416725
        transaction_length=322
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1617197608416725 (2021-03-31 21:33:28.416725 中国标准时间)
# immediate_commit_timestamp=1617197608416725 (2021-03-31 21:33:28.416725 中国标准时间)
/*!80001 SET @@session.original_commit_timestamp=1617197608416725*//*!*/;
/*!80014 SET @@session.original_server_version=80022*//*!*/;
/*!80014 SET @@session.immediate_server_version=80022*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 839
#210331 21:33:28 server id 1  end_log_pos 930 CRC32 0xf36aee76  Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1617197608/*!*/;
BEGIN
/*!*/;
# at 930
#210331 21:33:28 server id 1  end_log_pos 996 CRC32 0x89764960  Table_map: `backup_test`.`table_1` mapped to number 93
# at 996
#210331 21:33:28 server id 1  end_log_pos 1051 CRC32 0x928424a0         Update_rows: table id 93 flags: STMT_END_F

BINLOG '
KHpkYBMBAAAAQgAAAOQDAAAAAF0AAAAAAAEAC2JhY2t1cF90ZXN0AAd0YWJsZV8xAAIDDwL9AgIB
AQACASFgSXaJ
KHpkYB8BAAAANwAAABsEAAAAAF0AAAAAAAEAAgAC//8ADAAAAAIAMTIADAAAAAMAMjIyoCSEkg==
'/*!*/;
### UPDATE `backup_test`.`table_1`
### WHERE
###   @1=12
###   @2='12'
### SET
###   @1=12
###   @2='222'
# at 1051
#210331 21:33:28 server id 1  end_log_pos 1082 CRC32 0x9209a26e         Xid = 91
COMMIT/*!*/;
# at 1082
#210331 21:34:46 server id 1  end_log_pos 1126 CRC32 0x99ca794a         Rotate to binlog.000038  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

7.上述记录了我们在完整备份之后,执行的所有操作,现在我们恢复数据. mysqldump 备份会保存为sql文件

执行完整备份:table_3.sql: 

执行: mysqldump -u root -p backup_test < D:\software\mysql\backup\table_3.sql PS:插如不进去,手动执行的

 

重复binlog中的操作:

mysqlbinlog D:\software\mysql\mysql-8.0.22-winx64\data\binlog.000037 | mysql -u root -p 

就恢复了.

可以选择跳过错误操作,执行前和之后的sql操作,像官网上说的,每一步操作早binlog中都有行数的记录...

 

 

 

 

 

 

 

粉果布丁甜甜圈
关注
专栏目录
mysql备份和恢复方案
06-14
MySQL备份和恢复是数据库管理中的关键环节，旨在保护数据免受意外损失，如硬件故障、软件错误或数据损坏。在本方案中，我们将探讨两种主要的备份策略，并讨论如何实施有效的恢复计划，确保数据安全和应用程序的连续...
MySQL 8.0 高可用之如何解决从库数据被修改引起的主从同步错误
个人公众号：Alen的数据库学习笔记
12-29 4628
作者公众号，欢迎一起交流。 在MySQL主从复制过程中，由于各种原因，不可避免在复制过程中出现错误，那么在复制过程中出现错误该如何解决呢？本篇将演示基于普通复制模式和基于GTID复制模式由于从库数据被修改导致的主从不一致时，如何在从库跳过相应的错误。 1 常见错误 1）ERROR：1062 从库插入数据，发生唯一性冲突 2）ERROR：1032 从库找不到要删除的数据 3）ERROR：1452 无法在外键的表插入或者更新参考主键没有的数据 2 普通复制模式从库出现错误 2.1 模拟错误 .
mysql查看复制延时_MySQL 8 中复制延时的测量与监控剖析
weixin_39941732的博客
02-08 588
新增复制时间戳MySQL8在binlog文件中，对每一个事务(注意是事务，不是事件)都记录了两个时间戳：original_commit_timestamp和immediate_commit_timestamp，通过计算这两个时间戳的差来测量复制延时。这种延时的测量是基于事务(transaction)的，而不再是基于事件(event)。original_commit_timestamp： 在产生ma...
mysql_binlog格式分析，快速了解binlog日志格式
jioulongzi的专栏
12-19 1014
mysql binlog 日志解析及分析流程在mysql中，binlog记录了所有记录操作(insert,update,delete)当然也包括表变更等操作本篇文章将详细讲解binlog格式以及常见的问题，为广大道友快速入门！以下流程执行环境为:mysql8。
mysql数据库管理-MySQL日志的综合管理
oradbm的博客
01-13 825
Mysql日志包括二进欧制日志，错误日志，通用查询日志和慢查询日志，redo log和undo log还有relay log等类型，以下实验内容如何启动 查看删除各类日志，以及如何使用二进制日志恢复数据库。
一文读懂MySQL的binLog日志
Java之路艰难，要以高内聚低耦合的目标去设计
12-14 1万+
一文读懂MySQL的binLog日志
MySQL备份和恢复的最佳实践指南
11-21
MySQL 备份和恢复的最佳实践指南 MySQL 备份和恢复是数据库管理中至关重要的一环。本文将深入探讨 MySQL 备份和恢复的最佳实践指南，帮助数据库管理员在面临数据丢失或灾难恢复等问题时能够快速有效地处理。 备份...
linux centos MySql备份和恢复方案.zip
08-14
本资料包"linux centos MySql备份和恢复方案.zip"显然是为了帮助用户理解和实施在Linux CentOS环境中MySQL的备份与恢复策略。 首先，我们来谈谈MySQL备份的重要性。数据是任何业务的生命线，定期备份可以防止意外...
MySQL 备份和恢复
12-17
MySQL的备份和恢复是数据库管理的关键环节，确保数据的...总的来说，MySQL备份和恢复需要根据不同的表类型和需求选择合适的工具和策略。定期备份、测试恢复过程以及了解备份参数的正确使用是保证数据安全的关键步骤。
linux centos MySql备份和恢复方案.7z
10-08
以上就是关于"Linux CentOS MySql备份和恢复方案"的知识点详解，这些内容对于任何在Linux环境中管理MySQL数据库的IT专业人员都是至关重要的。通过合理备份和恢复策略，可以有效保护数据库的安全，确保业务连续性。
mysql配置bin log参数_Mysql配置参数sync_binlog说明
weixin_32476639的博客
01-19 678
MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。默认，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。如果sync_binlog>0，表示每sync_binlog次事务提交，M...
MySQL 一文带你详解 mysql binlog
小楼一夜听春雨，深巷明朝卖杏花
07-18 711
前言 我们都知道，binlog可以说是MySQL中比较重要的日志了，在日常学习及运维过程中，也经常会遇到。不清楚你对binlog了解多少呢？本篇文章将从binlog作用、binlog相关参数、解析binlog内容三个方面带你了解binlog。 1.binlog简介 binlog即binary log，二进制日志文件。它记录了数据库所有执行的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录并保存在二进制文件中。 binlog主要有两个应用场景，一是用于复制...
springboot + Mybatis-plus
姜姜的Blog
09-22 513
第一步：创建数据库 -- MySQL dump 10.13 Distrib 8.0.19, for Win64 (x86_64) -- -- Host: 127.0.0.1 Database: mmall -- ------------------------------------------------------ -- Server version 8.0.19 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */
MySQL导入.sql文件方法以及导入失败的问题解决
热门推荐
Gremmie的博客
10-17 1万+
本文着重介绍了如何应对sql文件导入以及外键创建失败,字符集不匹配等错误的解决方法
【数据库学习】——Python实现mysql数据库SQL文件生成和导入
python_AI_fans的博客
06-05 3958
【数据库学习】——Python实现mysql数据库SQL文件生成和导入
mysql-bin_MySQL - binlog日志简介及设置
weixin_36215364的博客
01-18 1318
基本概念binlog是Mysql sever层维护的一种二进制日志，与innodb引擎中的redo/undo log是完全不同的日志；其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句，记录了所有的DDL和DML(除了数据查询语句)语句，并以事务的形式保存在磁盘中，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。一般来说开启二进制日志大概会有1%的性能损耗(参见My...
《童虎学习笔记》6分钟学会MySQL基于时间点的恢复(position方式)
tonghu_note的博客
05-01 1229
1
MySQL之mysqldump的使用详解和记一次备库的恢复
q309572960的博客
04-30 898
说明: 以下所有操作针对与mysql8.0 一、mysqldump 简介 mysqldump 是 MySQL 自带的逻辑备份工具。 它的备份原理是通过协议连接到 MySQL 数据库，将需要备份的数据查询出来，将查询出的数据转换成对应的DML语句，当我们需要还原这些数据时，只要执行这些 DML语句，即可将对应的数据还原。（说白点就跟我们平时手动执行sql是一样的，先创建执行语句创建数据库,如何创建表，如果表存在则删除再创建，然后在执行插入，依次循环所有数据库） 如 使用mysqldump导出数据后的sql语句
解析mysqlbinlog日志_带你解析MySQL binlog
weixin_39781326的博客
12-22 547
前言：我们都知道，binlog可以说是MySQL中比较重要的日志了，在日常学习及运维过程中，也经常会遇到。不清楚你对binlog了解多少呢？本篇文章将从binlog作用、binlog相关参数、解析binlog内容三个方面带你了解binlog。1.binlog简介binlog即binary log，二进制日志文件。它记录了数据库所有执行的DDL和DML语句(除了数据查询语句select、show等)...
mysql备份和恢复数据
最新发布
08-31
MySQL 数据库备份和恢复是非常重要的数据库管理任务，它有助于防止数据丢失并确保在需要时能够快速恢复系统。以下是备份和恢复的基本步骤： **备份**: 1. **mysqldump**: MySQL 自带的命令行工具 `mysqldump` 可用于创建完整的数据库、表或特定查询的结果。例如，你可以使用 `mysqldump -u [username] -p [database_name] > backup.sql` 来备份整个数据库到一个SQL脚本文件。 2. **二进制日志备份**: 这是一种实时备份，记录了所有更改事务。通过 `mysqlbinlog` 工具可以读取和恢复这些日志。这种方式适用于生产环境，因为能提供更准确的点恢复。 3. **物理备份**: 对于大型数据库，还可以选择直接复制数据文件（.frm, .ibd 等）进行备份，但这通常需要数据库停止服务。 **恢复**: 1. **从SQL脚本恢复**: 使用 `mysql < backup.sql` 命令导入已备份的SQL文件到数据库。 2. **基于二进制日志恢复**: 如果使用二进制日志备份，先启动MySQL服务器，然后使用 `mysqlbinlog` 指定日志位置和起始时间，让其应用到目标数据库。 3. **物理恢复**: 将备份的数据库文件替换到相应的目录下，确保权限设置正确，并重启MySQL服务。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值