- GreatSQL社区原创内容未经受权不得随便应用,转载请分割小编并注明起源。
- GreatSQL是MySQL的国产分支版本,应用上与MySQL统一。
- 作者: 杨延昭
- 文章起源:GreatSQL社区投稿
在进行数据库备份的时候次要分为了逻辑备份和物理备份这两种形式。在数据迁徙和备份复原中应用mysqldump将数据生成sql进行保留是最罕用的形式之一。
本文将围绕着mysqldump的应用,工作原理,以及对于InnoDB和MyISAM两种不同引擎如何实现数据一致性这三个方面进行介绍。
一.mysqldump 简介
mysqldump是MySQL自带的逻辑备份工具。它的备份原理是通过协定连贯到 MySQL数据库,将须要备份的数据查问进去,将查问出的数据转换成对应的insert语句,当咱们须要还原这些数据时,只有执行这些insert语句,即可将对应的数据还原。
二.备份的命令
2.1命令的格局
1.mysqldump [选项] 数据库名 [表名] > 脚本名2.mysqldump [选项] --数据库名 [选项 表名] > 脚本名3.mysqldump [选项] --all-databases [选项] > 脚本名
2.2选项阐明
参数名 | 缩写 | 含意 |
---|---|---|
--host | -h | 服务器IP地址 |
--port | -P | 服务器端口号 |
--user | -u | MySQL 用户名 |
--pasword | -p | MySQL 明码 |
--databases | 指定要备份的数据库 | |
--all-databases | 备份mysql服务器上的所有数据库 | |
--compact | 压缩模式,产生更少的输入 | |
--comments | 增加正文信息 | |
--complete-insert | 输入实现的插入语句 | |
--lock-tables | 备份前,锁定所有数据库表 | |
--no-create-db/--no-create-info | 禁止生成创立数据库语句 | |
--force | 当呈现谬误时依然持续备份操作 | |
--default-character-set | 指定默认字符集 | |
--add-locks | 备份数据库表时锁定数据库表 |
三.还原的命令
3.1零碎行命令
mysqladmin -uroot -p create db_name mysql -uroot -p db_name < /backup/mysqldump/db_name.db注:在导入备份数据库前,db_name如果没有,是须要创立的; 而且与db_name.db中数据库名是一样的才能够导入。
3.2source形式
mysql > use db_name;mysql > source /backup/mysqldump/db_name.db;
四.mysqldump实现的原理
4.1备份流程如下
1.调用FWRL(flush tables with read lock),全局禁止读写2.开启快照读,获取此期间的快照(仅仅对innodb起作用)3.备份非innodb表数据(*.frm,*.myi,*.myd等)4.非innodb表备份结束之后,开释FTWRL5.逐个备份innodb表数据6.备份实现
4.2执行mysqldump,剖析备份日志
# 执行语句[root@localhost backup]# mysqldump -uroot -proot -h127.0.0.1 --all-databases --single-transaction --routines --events --triggers --master-data=2 --hex-blob --default-character-set=utf8mb4 --flush-logs --quick > all.sqlmysqldump: [Warning] Using a password on the command line interface can be insecure.[root@localhost ~]# tail -f /var/lib/mysql/localhost.log第一步: FLUSH /*!40101 LOCAL */ TABLES# 这里是刷新表第二步: FLUSH TABLES WITH READ LOCK# 因为开启了--master-data=2,这时就须要flush tables with read lock锁住全库, 记录过后的master_log_file和master_log_pos点 这里有一个疑难? 执行flush tables操作,并加一个全局读锁,那么以上两个命令貌似是反复的, 为什么不在第一次执行flush tables操作的时候加上锁呢? 简而言之,是为了防止较长的事务操作造成FLUSH TABLES WITH READ LOCK操作迟迟得不到 锁,但同时又阻塞了其它客户端操作。 第三步: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ# --single-transaction参数的作用,设置事务的隔离级别为可反复读, 即REPEATABLE READ,这样能保障在一个事务中所有雷同的查问读取到同样的数据, 也就大略保障了在dump期间,如果其余innodb引擎的线程批改了表的数据并提交, 对该dump线程的数据并无影响,然而这个还不够,还须要看下一条第四步: START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */# 获取以后数据库的快照,这个是由mysqldump中--single-transaction决定的。# WITH CONSISTENT SNAPSHOT可能保障在事务开启的时候,第一次查问的后果就是 事务开始时的数据A,即便这时其余线程将其数据批改为B,查的后果仍然是A。简而言之,就是开启事务并对所有表执行了一次SELECT操作,这样可保障备份时, 在任意工夫点执行select * from table失去的数据和 执行START TRANSACTION WITH CONSISTENT SNAPSHOT时的数据统一。 【留神】,WITH CONSISTENT SNAPSHOT只在RR隔离级别下无效。第五步: SHOW MASTER STATUS# 这个是由--master-data决定的,记录了开始备份时,binlog的状态信息, 包含MASTER_LOG_FILE和MASTER_LOG_POS这里须要特地辨别一下master-data和dump-slavemaster-data:--master-data=2示意在dump过程中记录主库的binlog和pos点,并在dump文件中正文掉这一行;--master-data=1示意在dump过程中记录主库的binlog和pos点,并在dump文件中不正文掉这一行,即复原时会执行;dump-slave--dump-slave=2示意在dump过程中,在从库dump,mysqldump过程也要在从库执行, 记录过后主库的binlog和pos点,并在dump文件中正文掉这一行;--dump-slave=1示意在dump过程中,在从库dump,mysqldump过程也要在从库执行, 记录过后主库的binlog和pos点,并在dump文件中不正文掉这一行; 第六步: UNLOCK TABLES# 开释锁。
五.mysqldump对InnoDB和MyISAM两种存储引擎进行备份的差别。
5.1对于反对事务的引擎如InnoDB,参数上是在备份的时候加上 –single-transaction 保证数据一致性
–single-transaction 实际上通过做了上面两个操作 :① 在开始的时候把该 session 的事务隔离级别设置成 repeatable read ;② 而后启动一个事务(执行 begin ),备份完结的时候完结该事务(执行 commit )有了这两个操作,在备份过程中,该 session 读到的数据都是启动备份时的数据(同一个点)。能够了解为对于 InnoDB 引擎来说加了该参数,备份开始时就曾经把要备份的数据定下来了,备份过程中的提交的事务时是看不到的,也不会备份进去。
5.2对于不反对事务的引擎如MyISAM,只能通过锁表来保证数据一致性,这里分两种状况:
1)导出全库:加 –lock-all-tables 参数,这会在备份开始的时候启动一个全局读锁 (执行 flush tables with read lock),其余 session 能够读取但不能更新数据, 备份过程中数据没有变动,所以最终失去的数据必定是完全一致的;2)导出单个库:加 –lock-tables 参数,这会在备份开始的时候锁该库的所有表, 其余 session 能够读但不能更新该库的所有表,该库的数据统一;
Enjoy GreatSQL :)
## 对于 GreatSQL
GreatSQL是由万里数据库保护的MySQL分支,专一于晋升MGR可靠性及性能,反对InnoDB并行查问个性,是实用于金融级利用的MySQL分支版本。
相干链接: GreatSQL社区 Gitee GitHub Bilibili
GreatSQL社区:
社区博客有奖征稿详情:https://greatsql.cn/thread-100-1-1.html
技术交换群:
微信:扫码增加GreatSQL社区助手
微信好友,发送验证信息加群
。