锐客网

  1. 首页 > 生活百科 > it技术 > >

mysql日志怎么备份 mysql的日志一般保存多久

IT技术备份

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模式 磁盘读写差别很大，说明读了很多未修改的页面 。
请点击输入图片描述
如何远程备份MySQL binlog远程备份mysql，可以通过执行如下备份命令:
mysqlbinlog --read-from-remote-server --raw --host=192.168.244.145 --port=3306 --user=repl --password=repl --stop-nevermysql-bin.000001
解释如下：
--read-from-remote-server：用于备份远程服务器的binlog 。如果不指定该选项，则会查找本地的binlog 。
--raw：binlog日志会以二进制格式存储在磁盘中，如果不指定该选项 ， 则会以文本形式保存 。
--user：复制的MySQL用户 ， 只需要授予REPLICATION SLAVE权限 。
--stop-never：mysqlbinlog可以只从远程服务器获取指定的几个binlog ， 也可将不断生成的binlog保存到本地 。指定此选项，代表只要远程服务器不关闭或者连接未断开，mysqlbinlog就会不断的复制远程服务器上的binlog 。
mysql-bin.000001：代表从哪个binlog开始复制 。
除了以上选项外，还有以下几个选项需要注意：
--stop-never-slave-server-id：在备份远程服务器的binlog时，mysqlbinlog本质上就相当于一个从服务器，该选项就是用来指定从服务器的server-id的 。默认为-1 。
--to-last-log：代表mysqlbinlog不仅能够获取指定的binlog，还能获取其后生成的binlog，获取完了，才终止 。如果指定了--stop-never选项则会隐式打开--to-last-log选项 。
--result-file：用于设置远程服务器的binlog，保存到本地的前缀 。譬如对于mysql-bin.000001，如果指定
--result-file=/test/backup-，则保存到本地后的文件名为/test/backup-mysql-bin.000001 。注
意：如果将--result-file设置为目录 ， 则一定要带上目录分隔符“/” 。譬如--result-file=/test/，而不是
--result-file=/test，不然保存到本地的文件名为/testmysql-bin.000001 。
MySQL 常用备份工具流程解析 下面我们就看一下常见的备份工具，以及目前最流行的 Percona XtraBackup 的备份流程 。
MySQL 常见的备份工具主要分为三种：
这里先说一下 binlog 备份 ， 它只是把 binlog 又复制了一份，并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复，无法单独进行数据恢复 。
mysqldump 备份出的文件就是 sql 文件，其核心就是对每个表执行 select ，然后转化成相应的 insert 语句 。mysqldump 的备份流程大致如下：
从上面可以看出在 mysqldump 备份期间 ， 备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更 ， 直到该库下的表备份完毕，这对于线上环境一般是无法接受的 。若是指定了--master-data或者 --dump-slave 则会在备份开始时加全局读锁（FLUSH TABLES WITH READ LOCK） ， 直到备份结束 。当然我们可以选一个从库进行备份，这样就不会影响线上业务 。另外使用 mysqldump 备份还有一个最大的好处，因为备份出来的是 sql 语句，所以它支持跨平台和跨版本的数据迁移或者恢复，这是物理备份无法做到的 。
但是也正是因为 mysqldump 备份出来的是 sql 语句，在使用时要更加注意，否则可能会酿成大祸 。例如，使用 mysqldump 常见的问题有：
所以使用 mysqldump 时一定要了解各个选项的作用，以及确认备份出来的 sql 文件里会有什么操作，会对现有数据造成什么影响 。
Mydumper 原理与 Mysqldump 原理类似，最大的区别是引入了多线程备份 ， 每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的 。这里不再单独介绍 。
Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具 ， 是基于 InnoDB 的崩溃恢复功能来实现的 。它的基本工作原理如下：
Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ，应用已提交的事务，回滚未提交的事物，将数据库恢复到一致性状态 。因为 Percona XtraBackup 备份出来的是物理文件，所以在使用备份出的文件进行恢复或者迁移时，不会像 mysqldump 那样会存在很多问题 。
使用 XtraBackup 备份时根据备份参数设置不同，对数据库的变更会造成不同程度的影响，具体影响会在下文分析 。
通过对比发现，XtraBackup 具有对数据库影响小，且能快速恢复的优点，在日常备份中是首?。籱ysqldump 使用相对更加灵活，但是使用是要注意对数据库原有数据的影响 。
备份策略主要有：全量备份和增量备份，再加上 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_dump文件；
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 和mysqldump选择哪个更好？
A5：通过上面的的解析，若是整个实例备份 ， 首先选择 Percona XtraBackup ，因为对数据库的影响最小 。若只是备份某个库表，这个就要视数据量而定，若数据量不大可以使用 mysqldump。注意 ， 对数据库做备份时最好选择业务连接最少的从库，因为备份也会消耗一定的资源，避免影响业务 。
怎么备份mysql binlog它是逻辑备份,优点可以备份各种存储引擎
1.备份所有的数据库
#mysqldump -uroot -p --all-database all.sql
2.备份指定的数据库
#mysqldump -uroot -p testtest.sql
3.备份指定数据库中的表
#mysqldump -uroot -p test stest_s.sql
备份完全恢复实例
(1)上午9点备份数据库
#mysqldump -uroot -p -l -F studentstudent.dmp
-l 给所有表加读锁
-F 生成一个新的日志文件
此时s表数据如下:
mysql select * from s;
------ ------- ------ -----------
| sno| sname | sex| address|
------ ------- ------ -----------
| 0901 | Jim| 1| shanghai|
| 0902 | helun | 2| beijing|
| 0903 | sam| 1| sichuan|
| 0904 | keke| 1| xizang|
| 0905 | gugu| 1| suzhou|
| 0906 | tang| 2| guangdong |
------ ------- ------ -----------
6 rows in set (0.00 sec)
备份完毕等到了student.dmp文件,还有mysql-bin.000012
(2)9点半备份完毕,然后插入新的数据
mysql insert into s values('0907','liu','1','jiangxi');
Query OK, 1 row affected (0.00 sec)
mysql insert into s values('0908','wang','2','wuxi');
Query OK, 1 row affected (0.00 sec)
(3)10点,数据库突然故障,数据无法访问.需要恢复备份:
#mysql -uroot -p studentstudent.dmp
恢复后的数据:
mysql select * from s;
------ ------- ------ -----------
| sno| sname | sex| address|
------ ------- ------ -----------
| 0901 | Jim| 1| shanghai|
| 0902 | helun | 2| beijing|
| 0903 | sam| 1| sichuan|
| 0904 | keke| 1| xizang|
| 0905 | gugu| 1| suzhou|
| 0906 | tang| 2| guangdong |
------ ------- ------ -----------
6 rows in set (0.00 sec)
(4)使用mysqlbinlog 恢复mysqldump 备份以来的BINLOG
#mysqlbinlog mysql-bin.000012 |mysql -uroot -p student
查询完全恢复后的数据:
mysql select * from s;
------ ------- ------ -----------
| sno| sname | sex| address|
------ ------- ------ -----------
| 0901 | Jim| 1| shanghai|
| 0902 | helun | 2| beijing|
| 0903 | sam| 1| sichuan|
| 0904 | keke| 1| xizang|
| 0905 | gugu| 1| suzhou|
| 0906 | tang| 2| guangdong |
| 0907 | liu| 1| jiangxi|
| 0908 | wang| 2| wuxi|
------ ------- ------ -----------
8 rows in set (0.00 sec)
恢复完成!
基于时间点的恢复(不完全恢复)
由于误操作,比如删除了一张表,使用完全恢复是没有用的,我们需要的是恢复到误操作之前的状态,然后跳过误操作语句,再恢复后面执行的语句,完成恢复;
例:
(1)上午10点发生误操作,可以用如下语句备份和BINLOG将数据恢复到故障前
#mysqlbinlog --stop-date="2010-10-31 9:59:59" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p
(2)跳过故障时间点,继续执行后面的BINLOG,完成恢复
#mysqlbinlog --start-date="2010-10-31 10:01:00" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p
基于位置恢复(不完全恢复)
和基于时间点恢复类是,但是更加精确.因为同一时间点可能有多条SQL语句执行;
例:
#mysqlbinlog --start-date="2010-10-31 9:55:00"--stop-date="2010-10-31 10:05:00" /usr/local/mysql/var/mysql-bin.000013/tmp/mysql_restore.sql
该命令将在/tmp/目录下创建小的文件,编辑它找到错误语句前后的位置号,例如前后位置号分别是368312 和 368315
(2)恢复了以前的备份文件后,输入
#mysqlbinlog --stop-position="368312" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p
#mysqlbinlog --start-position="368315" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p
Mysql备份恢复方案有哪些，全备 ， 热备该怎么做方案一：mysqldump全备份 日志增量备份
1， mysqldump备份方案：
周一凌晨3点 全备
周二到周日凌晨3点增量备份
2 ， 备份步骤
(1)创建备份目录，备份脚本存放目录
Shellmkdir /usr/mysqlbackup;
Shellchmod 755 /usr/mysqlbackup;
Shellmkdir /usr/mysqlbackup/daily;
Shellchmod 755 /usr/mysqlbackup/daily;
Shellmkdir /usr/script;
Shellchmod 777 /usr/script/*.sh
(2)启用二进制日志
如果日志没有启开，必须启用binlog，要重启mysqld，首先，关闭mysqld，打开/etc/my.cnf ， 加入以下几行：
[mysqld]
log-bin
然后重新启动mysqld，会产生hostname-bin.000001以及hostname-bin.index，前面的日志文件是记录所有对数据的更新操作，后面的文件是存储所有二进制文件的索引 ， 不能轻易被删除 。
(3)全备份，增量备份 。
详细见mysqlFullBackup.sh、mysqlDailyBackup.sh脚本（请注意脚本里面的备份目录、mysql软件安装目录、压缩文件名以及用户名密码 ， 如有不符，请修改） 。
下面是部分shell上单个手动执行的测试命令 。
Shell /usr/local/mysql/bin/mysqldump -uroot -pnYuIman25040slave201012301124 --no-create-info=FALSE --order-by-primary=FALSE --force=FALSE --no-data=https://www.04ip.com/post/FALSE --tz-utc=TRUE --flush-privileg
es=FALSE --compress=FALSE --replace=FALSE --insert-ignore=FALSE --extended-insert=TRUE --quote-names=TRUE --hex-blob=TRUE --complete-insert=FALSE --add-locks=TRUE --port=3306 --d
isable-keys=TRUE --delayed-insert=FALSE --create-options=TRUE --delete-master-logs=FALSE --comments=TRUE --default-character-set=utf8 --max_allowed_packet=1G --flush-logs=FALSE -
-dump-date=TRUE --lock-tables=TRUE --allow-keywords=FALSE --events=FALSE --single-transaction=TRUE --routines --all-databases/backup/mysql/full/mysql_20110104_195546.sql
(4)设置crontab任务，每天执行备份脚本
shell crontab –e
#每个星期日凌晨3:00执行完全备份脚本
#周一到周六凌晨3:00做增量备份
0 3 * * 1-6 /root/MySQLBackup/mysqlDailyBackup.sh /dev/null 21
(5)清除旧的备份文件 。
每天去看查看下备份磁盘空间，删除旧的备份压缩文件 。
MySQL的备份与还原，非常规备份，全量备份，增量备份1mysql日志怎么备份：官方百万级别mysql日志怎么备份的测试数据库mysql日志怎么备份：
官方测试数据库github网址：
下载到目录mysql日志怎么备份，解压即可，运行命令：
2：自己创建简单测试数据库：
快速随机生成测试语言的网站：
选择sql和想生成的字段 ， 点击生成Generate!生成即可 。
在MySQL输入生成的语句即可 。
3：测试备份还原时用到的命令
删库跑路测试（先备份好）
还原后查询库的表数据是否完整 。
采用复制整个数据存放目录
1：查看数据库数据存放位置
有两种方法：
1)：在数据库中用命令show variables like 'datadir';查看
2)：在配置文件中查看，配置mysql日志怎么备份了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的日志一般保存多久】mysql日志怎么备份的介绍就聊到这里吧，感谢你花时间阅读本站内容 ， 更多关于mysql的日志一般保存多久、mysql日志怎么备份的信息别忘了在本站进行查找喔 。

    推荐阅读


    上一篇：鸿蒙桌面小艺建议移除不了，鸿蒙系统桌面小艺建议怎么移除

    下一篇：gis图层属性的标注在哪，gis图层属性的标注在哪找