备份在MySQL怎么理解 备份MySQL

什么是数据库备份

对于MySQL数据库，备份与恢复相关的术语包括：备份(backup)、还原(restore)、恢复(recover)、二进制日志(binlog)，其中备份按照其特性可以分为：物理备份和逻辑备份;冷备、温备和热备;完全备份和不完全备份等;常用的备份工具包括：操作系统拷贝、mysqldump等;还原包括物理备份的还原和逻辑备份的还原;下面分别加以介绍和说明。

创新互联主要从事成都网站设计、成都网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务全州,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220

数据库备份通俗地说是将数据库的某一时刻的数据复制了一份;数据库还原是将备份出的数据替换掉原来数据库中的数据文件，将备份放回到原来数据库文件的目录位置;二进制日志(BINLOG)记录数据库的变更过程，例如创建数据库、建表、修改表等DDL操作、以及数据表的相关DML操作，这些操作会导致数据库产生变化，开启binlog以后导致数据库产生变化的操作会按照时间顺序以“事件”的形式记录到binlog二进制文件中。

参考上图，在凌晨2:00，管理员将已开启二进制日志的数据库的数据做了一个完整的备份，随着时间的推移，仍然有用户对数据库进行相关的写操作(包括：DDL语句、DML语句中的增删改操作、DCL授权语句和TCL事务处理语句等)，导致了二进制日志文件写满(默认1G)后自动切换;在上午9:37时，由于硬盘出现故障，数据库用户不能正常访问存放在硬盘中的数据库数据，此时如果数据库备份和二进制日志没有损坏，管理员是可以通过还原备份和恢复二进制日志的方式挽回数据损失的。

挽回数据损失的过程包括：1.更换新硬盘;2.还原备份;3.重做备份到故障时段的二进制日志中的语句等;正常情况不会造成数据的丢失，损失的仅仅是一段时间的停机时间。

上例中，还原数据备份时，数据库中的数据回到了备份时刻的状态，而二进制日志中记录了从备份到故障前一段时间内所有用户对数据库的写操作的语句，只要把这些语句按照时间顺序重新运行一遍，所还原的数据就会变成为故障前那一刻的状态，不会造成数据丢失。因此通常把保存在二进制日志中的语句重新执行的过程叫做恢复。

如何备份整个mysql数据库

1、首先打开mysql数据库软件进入软件主界面。

2、然后再左侧树里打开自己的的数据库。

3、然后需要点击需要备份的数据库名。

4、如图所示为打开数据库后界面。

5、然后需要点击转储sql文件选项。

6、然后需要打开选择存储文件路径并选择保存。

7、点击保存即可在路径备份好格式为sql的数据库文件。

Mysql的备份

在DOS环境下的操作，备份（也就是导出），

mysqldump -p123 --opt stu c:/stu.sql

其中123是数据库的密码，stu是数据库名，c:/stu.sql是要导出的位置。

还原（导入数据库到stu），

mysql -u root

use stu

source c:/stu.sql;

MySQL的备份与还原，非常规备份，全量备份，增量备份

1：官方百万级别的测试数据库：

官方测试数据库github网址：

下载到目录，解压即可，运行命令：

2：自己创建简单测试数据库：

快速随机生成测试语言的网站：

选择sql和想生成的字段，点击生成Generate!生成即可。

在MySQL输入生成的语句即可。

3：测试备份还原时用到的命令

删库跑路测试（先备份好）

还原后查询库的表数据是否完整。

采用复制整个数据存放目录

1：查看数据库数据存放位置

有两种方法：

1)：在数据库中用命令 show variables like 'datadir'; 查看

2)：在配置文件中查看，配置了 datadir 目录的可查看。没有配置的默认为 /var/lib/mysql/ 位置

Linux中查看配置文件

2：复制目录或者目录下某个数据库名

3：还原时直接复制文件夹到数据库目录即可

mysqldump又可叫做全量备份。

参数 --databases 同 -B ，单独一个库，也可省略。

1、备份命令mysqldump格式

格式：mysqldump -h主机名 -P端口 -u用户名 -p密码 database 数据库名 文件名.sql

备份testDatabase数据库

2、备份MySQL数据库为带删除表的格式

备份MySQL数据库为带删除表的格式，能够让该备份覆盖已有数据库而不需要手动删除原有数据库。

3、直接将MySQL数据库压缩备份

备份并压缩

4、备份MySQL数据库某个(些)表

备份testDatabase中的myTable表，不需要用参数 --databases 或者 -B

5、同时备份多个MySQL数据库

同时备份testDatabase和 employees两个库

6、备份服务器上所有数据库

参数 --all-databases 同 -A

7、还原MySQL数据库的命令

1) 不指定数据名还原，默认生成原数据库名称，还原所有数据库。

2) 指定数据名还原，还原指定单个数据库，需在数据库种预先创建一个testDatabase名称。

3) 还原压缩的MySQL数据库

4) 进入数据库用source导入

增量备份是针对于数据库的bin-log日志进行备份的，增量备份是在全量的基础上进行操作的。增量备份主要是靠mysql记录的bin-log日志。

1：查看是否开启bin-log日志

进入mysql输入命令可查看。

显示如下为开启状态，日志文件在/var/lib/mysql/以binlog.00001的格式保存。

如未开启，需要在配置文件种配置

2：查看目前使用的bin-log日志文件

进入mysql查看命令。

显示如下，目前使用的是binlog.000022文件，所有操作都记录在此文件。

查看当前testDatabase的表myTable数据如下，

3：刷新日志，使用新的日志文件（备份）

在命令端执行命令

日志文件从 binlog.000022 变为 binlog.000023

这时相当与已经备份成功，备份文件即为上次的binlog.000022日志文件。

4：删除数量，从日志还原数据

1) 删除ABC行

查询以及没有ABC行列。

2) 恢复数据ABC行

退出mysql，在命令端用mysqlbinlog命令恢复到binlog.000022日志状态。

进入数据库再次查看数据，ABC已经恢复。

增量备份完成。

如何实现MySQL数据库的备份与恢复

在数据库表丢失或损坏的情况下 备份你的数据库是很重要的 如果发生系统崩溃 你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态 有时 正是MySQL管理员造成破坏 管理员已经知道表以破坏 用诸如vi或Emacs等编辑器试图直接编辑它们 这对表绝对不是件好事！备份数据库两个主要方法是用mysqldump程序或直接拷贝数据库文件（如用cp cpio或tar等） 每种方法都有其优缺点 mysqldump与MySQL服务器协同操作 直接拷贝方法在服务器外部进行 并且你必须采取措施保证没有客户正在修改你将拷贝的表 如果你想用文件系统备份来备份数据库 也会发生同样的问题 如果数据库表在文件系统备份过程中被修改 进入备份的表文件主语不一致的状态 而对以后的恢复表将失去意义 文件系统备份与直接拷贝文件的区别是对后者你完全控制了备份过程 这样你能采取措施确保服务器让表不受干扰 mysqldump比直接拷贝要慢些 mysqldump生成能够移植到其它机器的文本文件 甚至那些有不同硬件结构的机器上 直接拷贝文件不能移植到其它机器上 除非你正在拷贝的表使用MyISAM存储格式 ISAM表只能在相似的硬件结构的机器上拷贝 在MySQL 中引入的MyISAM表存储格式解决了该问题 因为该格式是机器无关的 所以直接拷贝文件可以移植到具有不同硬件结构的机器上 只要满足两个条件 另一台机器必须也运行MySQL 或以后版本 而且文件必须以MyISAM格式表示 而不是ISAM格式 不管你使用哪种备份方法 如果你需要恢复数据库 有几个原则应该遵守 以确保最好的结果 定期实施备份 建立一个计划并严格遵守 让服务器执行更新日志 当你在崩溃后需要恢复数据时 更新日志将帮助你 在你用备份文件恢复数据到备份时的状态后 你可以通过运行更新日志中的查询再次运用备份后面的修改 这将数据库中的表恢复到崩溃发生时的状态 以文件系统备份的术语讲 数据库备份文件代表完全倾倒（full dump） 而更新日志代表渐进倾倒（incremental dump） 使用一种统一的和易理解的备份文件命名机制 象backup buckup 等不是特别有意义 当实施你的恢复时 你将浪费时间找出文件里是什么东西 你可能发觉用数据库名和日期构成备份文件名会很有用 例如 %mysqldump samp_db /usr/archives/mysql/samp_db %mysqldump menagerie /usr/archives/mysql/menagerie 你可能想在生成备份后压缩它们 备份一般都很大！你也需要让你的备份文件有过期期限以避免它们填满你的磁盘 就象你让你的日志文件过期那样 用文件系统备份备份你的备份文件 如果遇上了一个彻底崩溃 不仅清除了你的数据目录 也清除了包含你的数据库备份的磁盘驱动器 你将真正遇上了麻烦 也要备份你的更新日志 将你的备份文件放在不同于用于你的数据库的文件系统上 这将降低由于生成备份而填满包含数据目录的文件系统的可能性 用于创建备份的技术同样对拷贝数据库到另一台机器有用 最常见地 一个数据库被转移到了运行在另一台主机上的服务器 但是你也可以将数据转移到同一台主机上的另一个服务器 使用mysqldump备份和拷贝数据库 当你使用mysqldumo程序产生数据库备份文件时 缺省地 文件内容包含创建正在倾倒的表的CREATE语句和包含表中行数据的INSERT语句 换句话说 mysqldump产生的输出可在以后用作mysql的输入来重建数据库 你可以将整个数据库倾倒进一个单独的文本文件中 如下 %mysqldump samp_db /usr/archives/mysql/samp_db 输出文件的开头看起来象这样 # MySQL Dump ## Host: localhost Database: samp_db# # Server version alpha log## Table structure for table absence #CREATE TABLE absence(student_id int( ) unsigned DEFAULT NOT NULL date date DEFAULT NOT NULL PRIMARY KEY (student_id date));## Dumping data for table absence #INSERT INTO absence VALUES ( );INSERT INTO absence VALUES ( );INSERT INTO absence VALUES ( ); 文件剩下的部分有更多的INSERT和CREATE TABLE语句组成 如果你想压缩备份 使用类似如下的命令 %mysqldump samp_db | gzip /usr/archives/mysql/samp_db gz如果你要一个庞大的数据库 输出文件也将很庞大 可能难于管理 如果你愿意 你可以在mysqldump命令行的数据库名后列出单独的表名来倾到它们的内容 这将倾倒文件分成较小 更易于管理的文件 下例显示如何将samp_db数据库的一些表倾到进分开的文件中 %mysqldump samp_db student score event absence grapbook sql%mysqldump samp_db member president hist league sql如果你生成准备用于定期刷新另一个数据库内容的备份文件 你可能想用 add drop table选项 这告诉服务器将DROP TABLE IF EXISTS语句写入备份文件 然后 当你取出备份文件并把它装载进第二个数据库时 如果表已经存在 你不会得到一个错误 如果你倒出一个数据库以便能把数据库转移到另一个服务器 你甚至不必创建备份文件 要保证数据库存在于另一台主机 然后用管道倾倒数据库 这样mysql能直接读取mysqldump的输出 例如 你想从主机拷贝数据库samp_db到 可以这样很容易做到 %mysqladmin h create samp_db%mysqldump samp_db | mysql h samp_db以后 如果你想再次刷新上的数据库 跳过mysqladmin命令 但要对mysqldump加上 add drop table以避免的得到表已存在的错误 %mysqldump add drop table samp_db | mysql h samp_dbmysqldump其它有用的选项包括 flush logs和 lock tables组合将对你的数据库检查点有帮助 lock tables锁定你正在倾倒的所有表 而 flush logs关闭并重新打开更新日志文件 新的更新日志将只包括从备份点起的修改数据库的查询 这将设置你的更新日志检查点位备份时间 （然而如果你有需要执行个更新的客户 锁定所有表对备份期间的客户访问不是件好事 ）如果你使用 flush logs设置检查点到备份时 有可能最好是倾倒整个数据库 如果你倾倒单独的文件 较难将更新日志检查点与备份文件同步 在恢复期间 你通常按数据库为基础提取更新日志内容 对单个表没有提取更新的选择 所以你必须自己提取它们 缺省地 mysqldump在写入前将一个表的整个内容读进内存 这通常确实不必要 并且实际上如果你有一个大表 几乎是失败的 你可用 quick选项告诉mysqldump只要它检索出一行就写出每一行 为了进一步优化倾倒过程 使用 opt而不是 quick opt选项打开其它选项 加速数据的倾倒和把它们读回 用 opt实施备份可能是最常用的方法 因为备份速度上的优势 然而 要警告你 opt选项确实有代价 opt优化的是你的备份过程 不是其他客户对数据库的访问 opt选项通过一次锁定所有表阻止任何人更新你正在倾倒的任何表 你可在一般数据库访问上很容易看到其效果 当你的数据库一般非常频繁地使用 只是一天一次地调节备份 一个具有 opt的相反效果的选项是 dedayed 该选项使得mysqldump写出INSERT DELAYED语句而不是INSERT语句 如果你将数据文件装入另一个数据库并且你想是这个操作对可能出现在该数据库中的查询的影响最小 delayed对此很有帮助 press选项在你拷贝数据库到另一台机器上时很有帮助 因为它减少网络传输字节的数量 下面有一个例子 注意到 press对与远端主机上的服务器通信的程序才给出 而不是对与本地主机连接的程序 %mysqldump opt samp_db | mysql press h samp_dbmysqldump有很多选项 详见《MySQL参考手册》 使用直接拷贝数据库的备份和拷贝方法 另一种不涉及mysqldump备份数据库和表的方式是直接拷贝数据库表文件 典型地 这用诸如cp tar或cpio实用程序 本文的例子使用cp 当你使用一种直接备份方法时 你必须保证表不在被使用 如果服务器在你则正在拷贝一个表时改变它 拷贝就失去意义 保证你的拷贝完整性的最好方法是关闭服务器 拷贝文件 然后重启服务器 如果你不想关闭服务器 要在执行表检查的同时锁定服务器 如果服务器在运行 相同的制约也适用于拷贝文件 而且你应该使用相同的锁定协议让服务器 安静下来 假设服务器关闭或你已经锁定了你想拷贝的表 下列显示如何将整个samp_db数据库备份到一个备份目录（DATADIR表示服务器的数据目录） %cd DATADIR%cp r samp_db /usr/archive/mysql单个表可以如下备份 %cd DATADIR/samp_db%cp member * /usr/archive/mysql/samp_db%cp score * /usr/archive/mysql/samp_db 当你完成了备份时 你可 lishixinzhi/Article/program/MySQL/201311/29384

mysql的备份都有哪些方式？原理都是基于什么的，适用范围是什么？有详细解答的高手没

数据备份是数据容灾的最后一道防线，即便有着两地三中心的架构，备份也依然重要。如果备份出问题，备份时影响了交易业务，备份数据无法恢复，这些也是企业难以承受的。所以选择合适的备份工具尤为重要。

每个企业级数据库都会有配套的备份工具，MEB(MySQL Enterprise Backup)就是MySQL企业版中非常重要的工具之一，是为企业级客户提供的数据备份方案。

Xtrabackup一直作为MEB 开源版备胎而存在，从MySQL 8.0开始情况可能会变得有所不同。

在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB备份/恢复体验会更好，目前xtrabackup还不支持这些特性。

MySQL 企业版还有哪些功能？

特性1：Backup Lock

8.0之前使用xtrabackup或MEB做物理备份，为了保证备份时InnoDB引擎表与其他引擎数据文件、及binlog日志的一致性会上全局读锁，再拷贝非InnoDB文件，这期间MySQL会变成只读，数据无法写入。表数量越多，可能加上时间越长，如果使用的xtrabackup 不小心没加rsync参数，逐个拷贝frm文件，锁定时间会更长，对业务影响较大。

我曾遇到过部署在虚拟机的实例有12000多张表，当时使用的xtrabackup，备份脚本中没加rsync参数，结果锁了十几分钟，而MEB就没有这样的问题。

MySQL 8.0支持轻量级备份锁 LOCK INSTANCE FOR BACKUP，数据字典也重构了由InnoDB存储。若不创建非InnoDB表，MEB默认使用备份锁获取binlog日志一致性位置，并阻止DDL操作，但不影响DML操作。

只有InnoDB表，仅上备份锁

请点击输入图片描述

若有非InnoDB表，上全局锁

请点击输入图片描述

特性2：Redo Log Archiving

MEB能做到在线热备，备份时不影响数据库读写，这是利用了InnoDB事务日志，在备份期间持续监视redo log的变化，读取增量变化，写入到ibbackup_logfile，也就不需要上锁来保障备份一致性。(对非InnoDB的文件需要上读锁拷贝)

如果备份期间数据库写入负载特别大，而写入ibbackup_logfile速度较慢，redo log size也不大，很可能会出现ibbackup_logfile的写入速度跟不上redo log记录生成速度，redo log 空间不够时需要覆写日志文件，那么来不及写入ibbackup_logfile的记录会丢失，导致备份失败。

MEB 4.1对此做了优化，将redo log处理线程拆分成多线程分工合作，提高处理redo log的效率，降低了redo log覆写造成备份失败的概率，但redo log新增速度和ibbackup_logfile写入速度悬殊太大，问题依然会发生。

MySQL 8.0.17支持了redo log archiving 彻底解决了此问题，备份前设置innodb_redo_log_archive_dirs，指定redo log归档目录。MEB备份时自动开启日志归档，当checkpoint时会将旧记录归档到此目录，后续从归档文件中读取redo日志记录，避免了覆写可能导致的redo记录丢失。

请点击输入图片描述

注意：innodb_redo_log_archive_dirs 不能在数据目录下，目录权限要求是700

特性3：Page Tracking

Page Tracking 是为优化增量备份效率，减少不必要的数据页扫描。

增量备份当前有3种扫描模式：

page-track：利用LSN精确跟踪上次备份之后被修改页面，仅复制这些页面，效率最快。

optimistic：扫描上次备份之后被修改的InnoDB 数据文件中，找出并拷贝修改的页面。依赖系统时间，使用存在限制。

full-scan：扫描所有InnoDB数据文件，找出并拷贝自上次备份之后修改的页面，效率最慢

1、利用page-track增量备份，需先安装备份组件

mysql INSTALL COMPONENT "";

2、在全备前开启page-track

SELECT mysqlbackup_page_track_set(true);

3、全备之后，做增量备份时指定若满足page tracking条件，默认会使用page-track模式，否则会使用full-scan模式，也可以指定--incremental=page-track。

mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup

incremental-base有3种选择

last_backup：基于前一次备份做增备，前一次备份可能是增备，也可能是全备。这种方式全备之间可能会有多个增备，每次增量可能比较小，但恢复时需要逐个合并。

last_full_backup：基于前一次全备做增备。这种方式增备会越往后体积可能越大，但恢复时只需要合并最后一次增量备份。

dir：基于前一次的备份目录，前一次备份可能是增备，也可能是全备。

测试对比full-scan 和page-track ，在变更页小于总体50%的情况下 ，备份效率至少能有1倍的速度提升。

page-track 模式 磁盘读写均衡，说明读写的都是修改页面。

请点击输入图片描述

full-scan模式 磁盘读写差别很大，说明读了很多未修改的页面。

请点击输入图片描述