【MySQL 8.0 OCP 1Z0-908认证考试】题库精讲--第五讲mysqlbinlog与mysqldump(下)
此专题题目较多，因此分为上下两部分来讲，此为下篇。
完整版题库请到我的资源中下载，此为传送门。
https://download.csdn.net/download/kanon_lgt/85010419?spm=1001.2014.3001.5503
第一题
讲解
- 此题考查的是主从IO_Thread和SQL_Thread作用。
- IO_Thread：slave连接到master，从master拉取binlog到本地。
- SQL_Thread：slave本地解析并执行从master拉取过来的binlog。
选项C是SQL_Thread的作用。
因此，选项A正确。
第二题
讲解
- 此题考查的是mysqlpump与mysqldump的数据备份功能区别
- mysqldump：受限于历史原因，功能比较单一，无法备份SYS库
- mysqlpump：mysqldump的演进版本，功能强大，可以针对特定的库、表、用户等进行备份还原，也可以开启并行备份，并可以备份SYS、PS(Perormance_Schema)、ndbinfo。
看题目：
要求备份SYS和ndbinfo，直接排除mysqldump。
看选项：
选项C，mysqlpump --all-databases，虽然是指定all-databases，但其并不会备份sys和PS，如果要针对sys和PS以及ndbinfo进行备份，需要使用--include-databases来指定。
选项B，mysqlpump --include-databases=%，使用1个通配符%来指定要备份的数据库，那么SYS和PS以及ndbinfo就可以备份出来了。
因此，选项B正确。
第三题
讲解
- 此题考查的是mysqlbinlog的高级用法
mysqlbinlog解析binlog后，可以将解析得到的sql语句replay到其它库中，这个功能是通过rewrite-db来实现的。
比如要将mydb1的binlog回放到mydb2中，只需要--rewrite-db='mydb1->mydb2'。
此选项可以叠加使用，如：mysqlbinlog --rewrite-db='mydb1->mydb2' --rewrite-db='mydb3->mydb4' binlog.001111 | mysql。
但是切记，此功能有一个前提条件：
binlog是基于ROW格式存储的，这也是我们主从同步、MGR、Innodb Cluster的指定格式。
看选项：
因此，选项A正确。
第四题
讲解
- 此题考查的是备份binlog的作用
binlog，按照mysql的写事务提交顺序记录了mysql的所有写操作，包括增删改查等。
备份下这些binlog在特定情况下会有很重要的意义，比如：
- 数据库还原到特定时间点，binlog中记录的写事务，除了sql语句本身外，还包括这个事务的唯一binlog位置标记、时间戳等。据此可以还原数据库到某个特定事务或特定时间点。
- 数据库特定条件下的误操作回滚，当一些delete或update误操作造成数据丢失后，如果binlog是row格式记录的，可以解析binlog得到误操作的语句，通过重构这些语句可以得到误操作之前的原始数据，并据此回滚这些误操作。
看选项：
选项A，binlog都相当小，所以非常适合长期存储和灾难恢复，错误。一般情况下，binlog体积并不是很小，长期存储后会积累非常多，要据此做灾难恢复要历经很长的回放时间。
选项B，binlog可以一直用于误操作的回滚，错误。只有row format的格式才可以。
选项C，多个binlog可以用于还原数据。正确。
选项D，它们可以用来还原数据到某个时间点。正确。
选项E，多个binlog可以并行解析执行以加快还原数据的速度，错误。只能串行执行。
因此，选项CD正确。
第五题
讲解
- 此题考查的是mysql主从中各个线程的作用
mysql主从架构中，在主库和从库都存在若干关键线程，
从库存在2个关键线程：
- IO_Thread：连接主库binlog dump，拉取binlog。
- SQL_Thread：解析并执行从库从主库拉取过来的binlog（在从库本地存入relaylog）
主库存在1个关键线程：
- binlog dump：它负责本地binlog于从库的io_thread对接，并发送本地binlog到从库。
看选项：
选项A，这是binlog写入线程的作用。
选项B，这是从库上io_thread的作用。
选项C，主库本地读取binlog event并发送给slave。正确。
选项D，这是从库上sql_thread的作用。
因此，选项C正确。
第六题
讲解
- 此题考查的是mysqlpump的高级用法
看题目：
题目中描述，执行命令mysqlpump --exclude-databases=% --users
分析命令：
--exclude-databases=%，意思是排除所有的db schema，不做任何schema的备份
--users ，意思是将数据库中所有的账号导出，导出格式为CREATE USER语句和GRANT 语句。
看选项：
选项A，它创建所有元数据的逻辑备份，但是不包括表数据。错误。
选项B，它返回一个错误，因为应该用mysqldump。错误。
选项C，它创建一个账户数据库的逻辑备份。错误。
选项D，它创建mysql中账户的逻辑备份。正确。
因此，选项D正确。
第七题
讲解
- 此题考查的是mysql慢查询统计与分析工具mysqldumpslow
mysqldumpslow可以对mysql的慢查询日志文件进行统计，计算同一类型慢查询的次数、平均执行时间、最大执行时间、锁时间、行数等。
因此，选项E正确。
第八题
讲解
- 此题考查的是mysqlbinlog备份binlog的知识点
mysqlbinlog工具除了能解析binlog为sql语句外，还有一个功能就是备份binlog。
mysqlbinlog可以备份静态的binlog file，也可以连接到mysql server上做实时binlog 备份。
它备份出来的文件与binlog的格式是一模一样的，并不会以sql语句方式存储，而是继续以binlog的格式存储。
mysqlbinlog可以备份非加密binlog，也可以备份加密binlog，但加密的binlog备份后是以非加密方式存储
mysqlbinlog要备份binlog必须指明以下两个选项：
- --read-from-remote-server：连接到mysql server
- --raw：备份输出为binlog，而不是sql语句
举个例子：
- 静态备份binlog命令如下：(会备份000130和000131两个binlog，然后结束备份)
mysqlbinlog --read-from-remote-server --host=light210 --raw binlog.000130 binlog.000131
- 在线实时备份binlog命令如下：(会备份000130这个binlog，然后持续备份之后生成的binlog)
mysqlbinlog --read-from-remote-server --host=light210 --raw --stop-never binlog.000130
看选项：
选项A，binlog它们会被压缩，错误。binlog备份后格式不会变，除了加密binlog会被解密。
选项B，它们需要开启FIPS安全组件，错误。不需要FIPS。
选项C，备份后的文件是易于阅读的，错误。备份后还是binlog格式，不是sql语句。
选项D，备份后的数据跟之前mysql生成在磁盘的数据是同样格式的，正确。
选项E，它们比逻辑dump备份要快，因为只需要做文件级别的copy即可，正确。
因此，选项DE正确。
第九题
讲解
- 此题考查的是binlog的清理和夏洛的至理名言
binlog的过期清理非常重要，mysql清理过期日志有两种方式：
- 手动清理：purge binary logs
- 自动清理：binlog_expire_logs_seconds
重点讲下自动清理，mysql为过期binlog自动清理提供了2个参数：
- binlog_expire_logs_seconds：日志保留的秒数，默认是2592000 秒，也就是保留30天。
- expire_logs_days：日志保留的天数。
奇幻的是这两个参数可以同时设置，那么以谁为准呢？规则如下：
- 当这两个参数都不显式在my.cnf中配置的时候，mysql默认是以binlog_expire_logs_seconds=2592000为准。
- 当这两个参数中任何1个设置为非0值时，mysql会以设置的那个变量值为准。
- 当这两个参数都设置为非0值时，mysql会以binlog_expire_logs_seconds的值为准。
- 当mysql在运行中，且这两个参数中有任何一个显式指定为非0值的情况下，是无法将另一个直接动态设置为非0的，必须将binlog_expire_logs_seconds先动态设置为0才能修改expire_logs_days的值。
实际上，expire_logs_days是一个过期参数。在5.7之前通过这个参数进行粗粒度的控制，但在8.0中它被binlog_expire_logs_seconds这个更细粒度的参数替代。
所以，在实际生产环境中直接忽略这个参数(my.cnf中不要配置它)即可，专注于通过binlog_expire_logs_seconds来控制binlog的自动清理。
binlog_expire_logs_seconds=0表示binlog永不过期，永不清理。
从8.0.29开始，是的，8.0.29已经于昨天(2022-04-26 GA发布了)，mysql为binlog自动清理提供了另一个开关参数：binlog-expire-logs-auto-purge=ON|OFF
- 当binlog-expire-logs-auto-purge=ON时，开启日志自动清理，此时binlog_expire_logs_seconds生效，过期参数expire_logs_days也生效（如果你还是坚持用这个过期参数的话）。
- 当binlog-expire-logs-auto-purge=OFF时，关闭日志自动清理，此时binlog_expire_logs_seconds无效，过期参数expire_logs_days也生效（如果你还是坚持用这个过期参数的话）。
仔细琢磨下，你就说是不是吃多了撑的？
binlog-expire-logs-auto-purge=OFF与inlog_expire_logs_seconds=0有什么区别吗？作用是一样的，为什么引入这么多乱七八糟的参数呢？mysql内部也卷成这样了吗？
但是再仔细一想，其实有它的现实合理性，就比如我们在平时做项目时，各种项目经理一大堆，完事再弄一堆监理进来监理项目经理，又安排个项目经理Owner进来管理项目经理，其实真正干活的就1个做技术的。10万的项目给你安排出1000万的排场，最后被项目经理搞黄了。
夏洛说过一句话我很有感触：有的人活的是造型，有的人活的是人设，而哥，活的是本事。
所以，各位道友，学好技术，做个实力派，不要做那些整天绞尽脑汁只会耍嘴皮子凹造型的人设派，更不用受制于他们。
看题目：
题目描述mysql server空间被binlog耗尽，现在需要紧急清理binlog以释放空间，用哪两种方式可以快速实现这个需求呢？
看选项：
选项A，动态设置binlog_expire_logs_seconds后重启mysql server。错误。这样白设置了，因为没有写入my.cnf或mysqld-auto.cnf中的参数在重启后都会失效。
选项B，在my.cnf中配置binlog_expire_logs_seconds。错误。在my.cnf中配置的参数不重启并不会生效。
选项C，设置binlog_expire_logs_seconds=0并重启mysql server。错误。设置为0是永不清理。
选项D，SET PERSIST binlog_expire_logs_seconds，这种方式会在mysql-auto.cnf中记录参数值，但是不重启依然不会生效。
选项E和F，正式我们上面讲的内，如果你仔细看过那么自然可以理解。
所以，选项EF正确。
第十题
讲解
- 此题考查的是mysql数据导出方式
mysql导出数据方式很多，比如：
- select into outfile
- mysqldump
- mysqlpump
看选项
选项A，CLONE LOCAL DATA，这是clone插件的使用，它可以将mysql数据目录进行克隆，但得到的仍然是表空间，而非导出的数据。关于clone，我们在后面的专题会详细讲解。
选项B，select * into outfile，可行。但有个前提，注意--secure_file_priv的配置。
选项C，mysqlexport，我是没有找到这个命令或者工具。
选项D，mysql --batch，不要看到个batch就乱用，它的作用是对输出结果用tab符号进行格式化的。
选项E，mysqldump，老将了，管用。
因此，选项BE正确。
第十一题
讲解
- 此题考查的是mysqlbinlog解析binlog为明文SQL
binlog基于ROW格式是经过编码后存储在binlog中，无法直接打开binlog查看，要查看到binlog中的SQL事务语句，必须使用mysqlbinlog对binlog进行解析。解析中涉及到的关键参数为：
--verbose （-vv）
--base64-output=DECODE-ROWS
比如：
mysqlbinlog --base64-output=DECODE-ROWS --verbose binlog-001111.log
看题目：
题目中描述要查看binlog的log_file_position为NNNNNN位置的sql事务明文，那么mysqlbinlog必须定位到NNNNNN的位置，从NNNNNN位置开始或者结束于NNNNNN后面一个事务的ID都是可以的。
即start-position=NNNNNN或stop-position=(NNNNNN的下一个)
看选项：
选项BF是使用了--verbose来解析binlog
选项B和F的区别是，一个start-position=NNNNNN，一个stop-position=NNNNNN.
很显然，应该使用start-position=NNNNNN才能看到此事务。
如果使用stop-position=NNNNNN,那么刚好截止到这个事务就停止，不会解析这个事务。
因此，选项B正确。
第十二题
讲解
此题与上篇的第七题重复，此处拿出来在发一次，是因为有其他朋友对此题有不同意见。
而我也想起来考试时，这道题貌似是给我判定回答错误，而我当时选的就是BE。
实际上，这道题很难做出正确答案，错误率非常高。
各位道友如果有另外高见，请在评论区留言。
第十三题
讲解
此题也是与上篇的第十一题重复了，没别的意思，就是因为在整理题目的时候没注意，把它整理了两遍，并且题目序号已经排上，跳过去就接不上后面的专题题目序号了，只好发出来。
实际上，到了这里想必聪明的道友已经明白，上面两道重复的题目也是这一个原因，哈哈~
第五讲下篇完成。
作者：老哥讲数据库
简介：数据库高级架构师 | Oracle 11g&12c OCM | MySQL 5.7&8.0 OCP
原创文章，转载请注明来源。