当前位置:首页 » 数据仓库 » 数据库全量备份
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

数据库全量备份

发布时间: 2023-03-15 16:06:25

❶ oracle怎样完全备份

可以热备宴斗份:x0dx0asql> alter database begin backupx0dx0a然后退出SQL,将Oracle软件和数据文件直接拷贝x0dx0a等都拷贝完了,再进sqlplus 执行:x0dx0aSQL>alter database end backupx0dx0a然后将begin时刻到end时刻产生的归档也拷贝出来,x0dx0a这就完成了全备x0dx0ax0dx0a如果你要在oracle下备份整个数据库:可以用expdp方便的进行x0dx0aexpdp sys/XXX mpfile=XXXX.dmp directory=XXXXx0dx0a其中directory是在oracle下建立的文件夹对象名x0dx0a假如你晌孙磨没建立过x0dx0a那么首先执行create directory dpdata1 as 'd:\test\mp'x0dx0a然后把expdp这样凯隐写directory=dpdata1

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

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

官方测试数据库github网址:https://github.com/datacharmer/test_db

下载到目录,解压即可,运行命令:

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

快速随机生成测试语言的网站:https://generatedata.com/

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

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

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

删库跑路测试(先备份好)

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

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

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

有两种方法:

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

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

Linux中查看配置文件


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

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


mysqlmp又可叫做全量备份。

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

1、备份命令mysqlmp格式

格式:mysqlmp -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数据库

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

❹ 数据库SQL 如何完全备份

第1步,依次单击“开始”→“所有程序”→Microsoft
SQL
Server→“企业管理器”,打开“企业管理器”控制台窗口。
第2步,在企业管理器控制台窗口的左窗格中依次展开“Microsoft
SQL
Servers/SQL
Server组/local”目录树。然后用鼠标右键单击“数据库”选项,在弹出的快捷菜单中执行“所有任务”→“备份数据库”命令。
第3步,打开“SQL
Server
备份”对话框,然后单击“数据库”右侧的下拉三角,从中选择要备份的数据库名称(本例采用默认的Master数据库)。在“名称”编辑框中可以键入备份生成的文件名称。接着单击“添加”按钮。
第4步,在打开的“选择备份目的”对话框中,单击“文件名”编辑框右侧浏览按钮,打开“备份设备位置”对话框。在该对话框中找到本地硬盘中用于保存备份数据库文件的文件夹(本例为L:\SQLBackup文件夹),然后在“文件名”编辑框中为备份文件键入一个合适的名称。设置完成以后单击“确定”按钮。
第5步,回到“选择备份目的”对话框,可以在“文件名”编辑框中看到刚才所作的设置,单击“确定”按钮即可。
第6步,SQL
Server开始按照指定的备份目的对数据库进行备份,备份完成后会给出提示,单击“确定”按钮即可,

❺ 请问简述数据备份的三种方法

数据备份的三种方法如下:
1、完全备份。完全备份是指拷贝整个磁盘卷或逻辑磁盘的内容。
2、增量备份。增量备份即备份自从上次备份孙弯尺操作以来新改变的数据,这些新改变的数据或者是新产生的数据,或者是更新的数据。
3、差量备份。差量备份即拷贝所有新的数据,这些数据都是上一次完全备份后产生或者更新的,差量备份与增量备份类似,但也有不同。
备份是一种将文件系统或数据库系统中的数据加以复制,一旦发生灾难则高或错误操作时,得以方便而及时地恢复系统的有效数据和正常运作的方法。备份存储媒体既可以是逻辑驱动器(如硬盘)、独立的存储设备(如可移动磁盘),也可以是由自动转换器组织和控制的整个磁盘库或磁带库。最好将重要数据制作三个或三个以上的备份,并且放置在不同的场所,以利日后回存之用。
更多闹配关于简述数据备份的三种方法,进入:https://m.abcgonglue.com/ask/fa57b21615833038.html?zd查看更多内容

❻ MySQL 常用备份工具流程解析

下面我们就看一下常见的备份工具,以及目前最流行的 Percona XtraBackup 的备份流程。

MySQL 常见的备份工具主要分为三种:

这里先说一下 binlog 备份,它只是把 binlog 又复制了一份,并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复,无法单独进行数据恢复。

mysqlmp 备份出的文件就是 sql 文件,其核心就是对每个表执行 select ,然后转化成相应的 insert 语句。mysqlmp 的备份流程大致如下:

从上面可以看出在 mysqlmp 备份期间,备份到某个数据库时,该数据库下的表都会处于只读状态,无法对表进行任何变更,直到该库下的表备份完毕,这对于线上环境一般是无法接受的。若是指定了--master-data或者 --mp-slave 则会在备份开始时加全局读锁(FLUSH TABLES WITH READ LOCK),直到备份结束。当然我们可以选一个从库进行备份,这样就不会影响线上业务。另外使用 mysqlmp 备份还有一个最大的好处,因为备份出来的是 sql 语句,所以它支持跨平台和跨版本的数据迁移或者恢复,这是物理备份无法做到的。

但是也正是因为 mysqlmp 备份出来的是 sql 语句,在使用时要更加注意,否则可能会酿成大祸。例如,使用 mysqlmp 常见的问题有:

所以使用 mysqlmp 时一定要了解各个选项的作用,以及确认备份出来的 sql 文件里会有什么操作,会对现有数据造成什么影响。

Mymper 原理与 Mysqlmp 原理类似,最大的区别是引入了多线程备份,每个备份线程备份一部分表,当然并发粒度可以到行级,达到多线程备份的目的。这里不再单独介绍。

Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具,是基于 InnoDB 的崩溃恢复功能来实现的。它的基本工作原理如下:

Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ,应用已提交的事务,回滚未提交的事物,将数据库恢复到一致性状态。因为 Percona XtraBackup 备份出来的是物理文件,所以在使用备份出的文件进行恢复或者迁移时,不会像 mysqlmp 那样会存在很多问题。

使用 XtraBackup 备份时根据备份参数设置不同,对数据库的变更会造成不同程度的影响,具体影响会在下文分析。

通过对比发现,XtraBackup 具有对数据库影响小,且能快速恢复的优点,在日常备份中是首选;mysqlmp 使用相对更加灵活,但是使用是要注意对数据库原有数据的影响。

备份策略主要有:全量备份和增量备份,再加上 binlog 备份。

目前去哪儿网数据库备份主要采用 XtraBackup 全量备份 +binlog 备份。数据库的重要级别不同,全量备份的频率不同。备份程序主要架构如下:

说明:

Percona XtraBackup 是目前备份 MySQL 使用最广泛的工具。在备份过程中,数据库可以进行正常的读写或者其他变更操作,但是偶尔也会遇见备份引起的元数据锁,或提交事务时发现被 binlog lock 阻塞等情况。下面我们就看一下 Percona XtraBackup 的备份流程和加锁时机。

说明:以下对 Percona XtraBackup 的分析都是基于 2.4.23 的版本,其他版本会略有差别,但是关键步骤基本相同。

XtraBackup 在备份开始时,会创建一个后台线程,专门用于拷贝数据库的 redo log 。首先 XtraBackup 会扫描每组 redo log 的头部,找出当前的 checkpoint lsn ,然后从该 lsn 后顺序拷贝所有的 redo log ,包括后续新产生的 redo log 。该线程会一直持续到将非事务表完全拷贝完成,才会安全退出。备份日志输出中会记录拷贝开始时的 checkpoint lsn 。日志输出如下:

在拷贝ibd文件之前,会先扫描数据库的数据文件目录,获取ibdata1,undo tablespaces及所有的ibd文件列表,并会记录相应的 space id,因为在恢复时需要这些 space id来找到对应 doublewrite buffer里页面的内容,以及对应的redo log条目。然后开始循环拷贝ibdata1,undo tablespaces及所有的ibd文件。
这里可通过设置--parallel进行多线程备份,提高物理文件的拷贝效率。不设置则默认为1。

在所有ibd文件拷贝完成后,XtraBackup开始备份非ibd文件。这一部分的逻辑比较复杂,因为备份非ibd文件前需要加锁,具体是否会加锁主要受到--no-lock 参数设置的影响。

若是设置了--no-lock为TRUE,则不会使用"FLUSH TABLES WITH READ LOCK"去加全局读锁,但是若备份过程中对non-InnoDB表执行了DDL或者DML操作, 这会导致备份的不一致,恢复出来的数据就会有问题。所以是不建议将--no-lock为TRUE,默认值是FALSE,也就是在不指定该选项的情况下会在备份非ibd文件前加全局读锁。

下面我们结合源码来看看判断是否加全局锁这部分的具体流程逻辑:

流程图如下:

总结来看:

1)若--no-lock为FALSE(默认值),则先施加全局读锁,然后再进行拷贝文件,另外若 --safe-slave-backup 设置为TRUE ,则会在加全局锁之前关闭SQL_THREAD线程;

2)若--no-lock为TRUE,则不会施加锁,直接进行拷贝文件。

加锁的逻辑主要由lock_tables_maybe实现,先看一下lock_tables_maybe源代码,如下:

lock_tables_maybe 函数简化处理流程如下:

1)若备份实例上已经加锁( LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK)或者设置lock-ddl-per-table 则直接返回;

2)若支持备份锁,则执行LOCK TABLES FOR BACKUP;

3)若不支持备份锁,则执行 FLUSH TABLES WITH READ LOCK。根据相应选项设置,在执行该操作前会判断是否有执行中的DDL/DML,以及等待超时时间,是否kill 对应的未结束的事务等。

从上文中我们还看到一个参数--safe-slave-backup ,该参数的主要作用是:

若是在从库执行的备份操作时设置了该参数,可以防止因从库同步主库操作,而导致XtraBackup长时间请求不到锁而造成备份失败。

若是设置了 --safe-slave-backup 为TRUE,那么会执行"STOP SLAVE SQL_THREAD",并等待Slave_open_temp_tables 为零才开始拷贝非 ibd 文件,Slave_open_temp_tables 为零说明SQL thread执行的事务都已经完成,这样就能保证备份的一致性。并且此时也不会有在执行的事务阻塞 XtraBackup 施加全局锁。

备份完非 ibd 文件后,将会备份 slave 和 binlog 信息。

mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意,在支持备份锁的实例上备份,指定了 --slave-info 或--binlog-info 均会先施加 binlog 备份锁( LOCK BINLOG FOR BACKUP),这会阻塞任何会更改 binlog 位点的操作。

备份完数据库的所有文件和binlog等相关信息,备份工作就基本完成了,之后主要执行的操作如下:

1)执行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",将所有的redo log刷盘;

2)停止redo log复制线程;

3)释放全局读锁(备份锁),binlog锁;

4)开启SQL_THREAD;

5)拷贝ib_buffer_pool和ib_lru_mp文件;

6)生成配置文件backup-my.cnf;

7)打印备份信息到xtrabackup_info文件,这些信息主要包含备份时使用的参数信息,备份起止时间,binlog位点信息,以及将会回到的lsn点。

下面是xtrabackup_info记录的部分内容:

加锁对应的函数是 mdl_lock_tables ,释放锁对应的函数是 mdl_unlock_all,主要是执行COMMIT,结束 mdl_lock_tables 中开启的显式事务,来释放MDL锁。mdl_lock_tables 流程如下:

上面参数--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之后添加的,因为 MySQL 5.7 新增了一个叫做 Sorted Index Builds 的功能,这会导致某些 DDL 操作不记录重做日志而导致备份失败。使用--lock-ddl或--lock-ddl-per-table 就会在备份开始时施加锁,阻止 DDL 操作。

另外,若备份时指定了--lock-ddl或--lock-ddl-per-table,则在备份非 ibd 文件时就不是再有加锁操作。

注意:LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 语句只有在支持备份锁的实例上才会执行,Percona Server for MySQL已经在 5.6.16-64.0 版本开始支持这种更加轻量的备份锁。

Q1: 使用 XtraBackup 备份的文件进行恢复时,恢复到哪个时间点? A1:恢复到执行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的时间点,因为这时任何改变 binlog 位点的操作都会被阻塞,redo log和binlog 是一致的。

Q2: 在开启 binlog 的情况下,MySQL 的奔溃恢复是同时依赖 binlog 和 redo log 这两种日志的,为什么XtraBackup 不用备份binlog?

A2:因为在备份中有执行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK,阻止了任何改变binlog位点的操作,这样只需要根据redo log将有commit log 的事务提交,没有commit log的事务进行回滚即可。

Q3: 使用Percona XtraBackup备份完成后redo的位点是和binlog是一样还是比binlog多一些?

A3:通过分析备份流程可以发现备份 binlog 位点信息(加binlog锁)是发生在停止 redo 拷贝线程前,而释放锁是在停止 redo 拷贝线之后,所以 redo log 会多一些。锁住了 binlog 保证了在该 binlog 位点前已经提交的事务的 redo log 都有 commit log 的信息,未提交的事物也就没有对应的 commit log 的信息,即便在锁住 binlog 后有 Innodb 表新的 DML 产生的 redo log ,但是事务无法提交,也就没有 commit log 的信息的,最后在回放的过程中对没有 commit log 的事务进行回滚就可以了。

Q4:Percona XtraBackup什么时候会加锁,以及影响加锁时间长度的因素有哪些?

A4:上面进行了分析,加锁操作只在备份非 ibd 文件时执行,加锁时长主要和非事务表的数量和大小有关,非事务表的数量越多,体积越大,拷贝文件所用的时间越长,那么加锁时间也就越长。也会和 redo log 生成的速度有关,只是 redo log 刷盘受到多个因素的影响,未及时刷盘的 redo log 一般很小。

Q5:Percona XtraBackup 和mysqlmp选择哪个更好?

A5:通过上面的的解析,若是整个实例备份,首先选择 Percona XtraBackup ,因为对数据库的影响最小。若只是备份某个库表,这个就要视数据量而定,若数据量不大可以使用 mysqlmp 。注意,对数据库做备份时最好选择业务连接最少的从库,因为备份也会消耗一定的资源,避免影响业务。

❼ 数据库,增量同步和全量同步是什么

增量同步和全量同步是数据库同步的两种方式。全量同步是一次性同步全部数据,增量同步则只同步两个数据库不同的部分。

❽ ORACLE全备份和0级增量备份的区别

ORACLE全备份和0级增量备份的区别:
1、Level 0级就是对数据库一个全库备份,增量备份必须从0级开始,也就是说必须要有一个全库备份当基础。
2、如果做全库备份oracle也不认为这是level 0的全库备份,尽管是一样的也要单独做一次level 0。
3、有了level 0当基础才能有后面的 level 1 level 2 level 3 level 4。
全量备份:
1.导出epmssit数据库备份;
exp system/sysadmin@hnepms file=d:\datas\epmssit_bak20100401.dmp owner=epmssit
2.创建epmsprd用户以及表空间;
sqlplus "/as sysdba"
create tablespace epmsprd datafile 'D:\datas\epmsprd.ora' size 100M;
create user epmsprd identified by epmsprd default tablespace epmsprd;
grant resource,connect to epmsprd;
3.将epmssit导入到epmsprd用户;
imp system/sysadmin@hnepms file=d:\datas\epmssit_bak20100401.dmp fromuser=epmssit touser=epmsprd
4.清理epmsprd数据库中的垃圾数据;
delete from xxxxxx;
5.备份epmsprd;
exp system/sysadmin@hnepms file=d:\datas\epmsprd_bak20100401.dmp owner=epmsprd

❾ 数据库备份主要包括哪三种方式

全量备份是指对某一时间点上的所有数据进行全量备份,包括系统和所有数据。这种备份方式每次都需要对系统和所有数据进行一次全量备份。这种备份方式最大的好处就是在恢复丢失数据时,只需要对一个完整的备份进行操作就能够恢复丢失数据,大大加快了系统或数据恢复的时间。
增量备份即在第一次全量备份的基础上,分别记录每次的变化。由于增量备份在备份前会判断数据是否发生变化,并仅记录每次变化情况,所以相较于其他两种备份方悄雹肆式它最大的好处在于其所需存储空间最少的(相同的变化情况下),备份速度最快的。当然在数据还原上来说,它的恢复时间是最长的,效率较低。恢复数据时,需要在第一次完备的基础上,整合每次的一肆逗个变化情况。
差异备份就是在第一次全量备份的基础上,记录最新数据较第一次全量备份的差异。简单来说,差异备份就是一个积累变化的过程。因此启轿,恢复系统或者数据时,只需要先恢复全量备份,然后恢复最后一次的差异备份即可完成。所以差异备份占用的储存空间和所需恢复时间介于全量备份和增量备份之间。