此专题题目较多，因此分为上下两部分来讲，此为上篇。
完整版题库请到我的资源中下载，此为传送门。
https://download.csdn.net/download/kanon_lgt/85010419?spm=1001.2014.3001.5503
第一题
讲解：
- 此题考查的是mysqldump的参数项作用。
mysqldump后可以配置很多参数选项，具体请看官方文档 。
此处讲下--no-create-db、--no-create-info、--no-tablespaces三个选项的含义：
- --no-create-db：在导出的结果文件中不包括CREATE DATABASE语句；
- --no-create-info：在导出的结果文件中不包括CREATE TABLE语句[为什么官方不设置为--no-create-table呢？]；
- --no-tablespaces：在导出的结果文件中不包括CREATE TABLESPACE和CREATE LOGFILE GROUP语句。
也许你会问，我平时在导出的时候本来也没加--no-tablespaces选项，在dump文件中也没看到CREATE TABLESPACE语句的，这是为什么呢？不瞒你说，我也没看到。我做过很多测试都没有成功把tablespace的定义导出，即使我在数据库中通过CREATE TABLESPACE定义了新的tablespace，并且在此表空间中创建了一个表，还是不能将其定义导出。
期待有学历高的道友给一个指点。
当然这并不影响我们对此题做出解答。
因此，选项C正确。
第二题
讲解：
- 此题考查的是binlog的解析与重放知识点。
binlog中记录了mysql的所有写事务，每个事务都有1个对应的position，可以理解为此事务的唯一ID。mysqlbinlog可以将binlog文件解析为普通的SQL语句，这些SQL语句只需要在mysql中重放一次即可恢复数据，配置position ID可以精确控制到回放某个事务或某些事务。
看题目：
题目中描述你手残或者脑残，不小心把数据库里的数据DELETE掉了，你们的业务部门经过了一通烧脑后，帮你推算出在某个binlog的某个position ID之后的事务重放一下即可恢复出删除前数据，这个binog就是000008号，position ID是1797。现在，让你来操作这个回放。
想来想去，你决定这样回放可能比较靠谱：
mysqlbinlog binlog.000008 --start-position=1798 | mysql -uroot -p 数据库名称
看选项：
选项A，这个无厘头了，题目并没有表明是异机数据丢失或从异机取得binlog。
选项B，符合你的想法，在binlog解析后通过管道符号直接输出给mysql客户端进行重放。
选项C，必须加上stop-position=1797，实际上你应该从1798开始才对。
选项D，不需要做什么它就会自动恢复，错了，mysqlbinlog只是解析，并不执行。
因此，选项B正确。
第三题
讲解：
- 此题考查的是mysqlpump的参数项作用的知识点。
先看题目，要求导出以db开头的数据库，比如db1、dbhr等。
从选项看，4个选项都是使用的mysqldump，但很可能是题目出错了， 因为4个选项都不是正确选项。有杠友可能会杠了，选项C不可以吗？很遗憾，真不可以。mysqldump没有include-databases这个参数选项，这是mysqlpump的功能。
正确写法是:mysqlpump --include-databases=db% --result-file=db.sql
另外，mysqlpump还有与之相反的选项--exclude-databases，此选项是排除指定的数据库。
扩展开，其还具备--include-tables、--exclude-tables、--include-users、--exclude-users等一系列高级用法。
这都是mysqldump不具备的功能。
所以，我认为此题可能是出错了，出题者要考查的应该就是mysqlpump配合include-databases
因此，如果考试中出现此题，注意看选项是不是mysqlpump。
如果选项都是mysqldump，那么勉强可以选择选项D
如果选项中有mysqlpump，并且搭配include-databases=db%,那么应该选择这个选项。
从此题也可以得到提示，我们在平时应该用mysqlpump替代mysqldump了。
第四题
讲解：
- 此题考查的是使用binlog重放数据库的知识点。
这道题出得非常妙，请道友们一定仔细琢磨明白，关系到你今后删库是否需要跑路的问题。
看题目：
题目描述，你这次又手残或者脑残了，而且比上次还残，上次你做了DELETE，这次你直接DROP了一个叫rental的表。但是，好在你有了上次的经验，这次没那么慌，冷静下来后你又烧脑起来，对binlog进行了仔细分析后，你成功又找到了自救的方法：找到DROP TABLE rental语句所在的binlog是log-bin.000036，并且定位到该语句的position ID为500324，时间是14:55:16（这个时间很有真实了，这个点正是下午犯困容易脑残的时候）。
OK，开始重新replay binlog把数据找回来，步骤如下：
- 先用之前的某个全备还原数据库，按题目意思，你还原后刚好接上000036这个binlog的开头(命好，可以少replay几个binlog了)。
- 再用000036这个binlog开始replay，但是要在position ID为500324处停止replay，这个不用解释吧。
那么怎么停止呢？这个本题考点。
看选项：
选项A，--stop-position=500324，完美匹配。
选项B，--stop-datetime='2019-11-20 14:55:16 '，貌似这个选项也可以啊。停在这个DROP的时间点。但是，你忽略了一个逻辑：当你的数据库并发很高时，在同一秒内会有很多个事务写入数据库，你直接停在这一秒，DROP是避开了，DROP之前的INSERT或者UPDATE呢？也避开了，这就丢失数据了。
选项C，--stop-position=500453,晚了，这个DROP又被执行了一次。
选项D，--stop-position='2019-11-20 14:55:18'，同C，晚了。
因此，选项A正确。
第五题
讲解：
- 此题考查的是mysqldump的选项知识点。
看题目：
mysqldump，要求master-data=2 --single-transaction，
首先，理解下master-data选项，在8.0.23之前叫master-data，在8.0.23之后叫source-data，为什么改名呢，关注黑名贵的道友应该都了解的，一波政治正确，让master和slave成了禁词。
master-data是为了在做完mysqldump后得到的dump文件可以用于创建一个新的slave节点，它在dump文件中记录了dump时刻的binlog-file和position id，内容如下：
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=18616
- master-data=2，以上SQL语句是被注释掉的；
- master-data=1，以上SQL语句是开放非注释掉的；
当使用master-data时，它会自动发出一个LOCK TABLES和UNLOCK TABLES的命令；
然后，再理解下single-transaction选项，这个是好东西，它确保事务一致性，既然是事务一致性，那么很显然，它只针对innodb和ndb引擎了，其它非事务引擎并不支持。它会对数据库的隔离级别进行设置，将其设置为RR(REPEATABLE READ)，且会开启一个事务(START TRANSACTION),作为前提，它会先FLUSH TABLES WITH READ LOCK一下，然后才会设置RR并START TRANSACTION，当得到MASTER STATUS后，便会UNLOCK TABLES。
要注意，single-transaction会带来副作用，便是非一致性读。
最后，当master-data和single-transaction一起出现时，master-data的锁会为single-transaction的锁降级，也就是不再LOCK ALL TBALES，而是以READ LOCK为优先。
看选项：
选项A，这是一个冷备，显然错误。
选项B，会执行一个flush tables with read lock，正确。
选项C，它对所有引擎都能确保一个一致性备份，错误，只有事务性引擎可以。
选项D，使用了READ COMMITED隔离级别，错误，是Repeatable Read。
选项E，这个备份是一个数据一致性的，正确。
因此，选项BE正确。
第六题
讲解
- 此题考查的是mysql主从同步安全中的binlog 加密的知识点。
mysql主从同步安全包括以下三点：
- 主从同步connection加密
- 主从同步binlog和relaylog加密
- 主从同步账户权限安全
此题考查的恰恰就是binlog加密
binlog_encryption = ON 开启binlog和relaylog加密
binlog不开启照样可以开启binlog加密
它采用两段式加密：
第一阶段每个binlog会有一个独立的password用于加密binlog自己
第二阶段需要一个keyring存储master key，它用来加密每个binlog的passwords
解密时也是两段：
第一阶段master key解密password
第二阶段password解密binlog
当master key丢失后可以重新创建master key，然后给每个password再重新加密，但password加密过的binlog或relaylog无需重新加密。
当开启binlog_encryption后，启动mysql server时会先创建master key，然后才会创建binlog或relaylog以及他们的password，master key对password加密存储，而password对binlog或relaylog加密存储。
当没开启binlog_encryption时，启动mysql server则不会开启加密，也不会创建master key；但在启动mysql server后再开启binlog_encryption,那么会立刻创建master key，并会立刻flush logs切割binlog，同时创建这个binlog的password用于加密新的binlog；但已经存在的旧binlog则不会被加密。
同理，当本来mysql server运行且开启着binlog_encryption的状态时，关闭binlog_encryption后会立刻flush logs切割binlog，新的binlog不再被加密，旧的已经加密的binlog则不会被自动解密，但mysql server依然可以读取他们。
mysqlbinlog不能直接读取加密的binlog，因为它没有master key无法解密password，但它可以通过mysql server来解密这些binlog，方法很变通：利用read-from-remote-server选项，这个选项会经过mysql server处理并传输出binlog，并交给mysqlbinlog。所以对于加密的binlog，mysql server刚好帮mysqlbinlog做了一次解密。
看选项：
选项A，它需要一个keyring plugin，正确。keyring plugin或component用于存储master key
选项B，它可以在运行时设置，正确。mysql server运行中依然可以开启binlog加密
选项C，它可以针对每个session级别来开启，错误。只能针对server级别开启或关闭
选项D，它加密任何来自slave的连接线程，错误。它不加密连接或者线程。
选项E，当开启加密时，会自动对已经存在的binlog做加密，错误。已经存在的不会被加密。
选项F，它要求log-bin=on，即开启binlog时才允许开启加密，错误。log-bin=off依然可以开启加密。
因此，选项AB正确。
第七题
讲解
- 此题考查的是mysqldump的选项知识点。
看题目：
有binlog.000001到binlog.000301的binlog文件，
mysqldump配合以下两个选项进行数据导出：
- delete-master-logs:会在导出后执行PURGE BINARY LOGS TO 'binlog.000302'
- all-databases: 会导出mysql库、以及用户自己创建的库，但不会导出PS(performance_schema)和IS(information_schema)；
看选项：
选项A，所有的数据库都会被导出到dump文件。错误。PS和IS不会导出。
选项C，所有的binlog都被删除。错误。会有一个新binlog生成，不会删除。
选项D，所有的binlog都被备份然后删除。错误。没有做任何binlog备份。
选项F，所有被删除的binlog细节和master metadata都被记录到dump文件中。错误。删除的binlog没有被记录进去。
选项B，所有的non-active binlog都被删除。
选项E，所有数据库，除了master metadata，都会被备份到dump文件中。
因此，选项BE正确。
第八题
讲解
- 此题考查的是mysqlbinlog解析binlog的知识点。
看题目：
此题很多关键信息隐含在题目描述中，影响对答案的选择，
- 一个严谨的科学的数据收集应用使用了mysql实例作为后台的数据管理
- 有每秒钟几千个高并发的易变数据事务
- 现在要还原使用跨度为10天的binlog来做数据库还原
问你，哪两个因素会导致还原出来的数据库跟之前的数据不一致？
看看它的还原命令：
mysqlbinlog \ --start-datetime='2019-08-01 11:00:00' \ --end-datetime='2019-08-10 08:30:25' \ binlog.000238 binlog.000239 binlog.000240 | mysql这个命令叠加使用了多个binlog一起解析，这样做的优点是可以避免临时表在多个binlog间上下文切换丢失的问题，举例如下：
如果使用多个mysqlbinlog来解析多个binlog，应该这样：
mysqlbinlog binlog.000238 | mysql mysqlbinlog binlog.000239 | mysql mysqlbinlog binlog.000240 | mysql你会说看起来跟叠加使用并没有不同啊？但假如在binlog.000238中创建了一个临时表CREATE TEMPORARY TABLE t1呢？那么这种用法在000239中如果使用到这个临时表t1，就会直接报错找不到表t1，因为000238在解析完成后session结束，临时表清空了。下一个session给000239自然找不到它了。
而叠加解析多个binlog则不会出现这个问题，因为session没有结束，临时表仍然在。
看选项:
选项A，临时表不能跨多个binlog持久化，错误。选项描述是对的，但这种叠加解析恰恰就是为了解决这个问题的。
选项B，多个binlog不能被叠加在一个mysqlbinlog命令，错误。
选项C，这些临时的值不能提供足够的精度。
选项D，这些binlog时间跨度太长，不能还原。
选项E，事务率太高以至于不能得到一个一致性的还原。
看选项CDE，感觉都不对，但仔细分析选项D更不对，不能因为时间跨度长就无法还原，跨度达几个月的我们同样还原过。选项C和E，正好扣题，每秒几千个易变临时数据，很容易造成数据不一致。
因此，选项CE正确。
第九题
讲解
- 此题考查的是异步主从复制中binlog的作用。
异步主从复制，包括半同步复制，其master上的binlog作用都是记录master的写事务日志并传递给slave进行replay。
master的binlog是slave主动拉取的。
因此，选项AE正确。
第十题
讲解
- 此题考查的是binlog切换的知识点
在什么情况下，mysql会切换binlog呢？
- 当前binlog写满，所谓写满是指binlog的大小达到了max_binlog_size大小的限制，且一个事务完成。（若1个事务很大，即使binlog超出了max_binlog_size也不会切换，直到这个大事务完成。）
- flush logs
- reset master
- restart mysql server
因此，选项BF正确。
第十一题
讲解
此题考查的是依然是binlog的作用
binlog有以下作用：
- 主从复制时同步数据
- 用于数据还原
因此，选项BD正确。
第十二题
讲解
- 此题考查的是mysqlpump用法
看题目：
直接使用mysqlpump默认用法，未加任何附加选项对数据库进行导出。
这种情况下，默认隐含的是--all-databases。
但是你以为--all-databases就是你以为的all-databases吗？错。
这里面不包括SYS、PS(performance_schema)、IS(information_schema)。
如果你想备份SYS和PS，必须使用--include-databases=sys,performance_schema来显示指明，
但是对于IS，即使你显示指明，它也不会导出，它会直接报错：
mysqlpump: [ERROR] (1) Dumping 'INFORMATION_SCHEMA' DB content is not supported.
看选项：
因此，选项CE正确。
第五讲上篇完成。
作者：老哥讲数据库
简介：数据库高级架构师 | Oracle 11g&12c OCM | MySQL 5.7&8.0 OCP
原创文章，转载请注明来源。
2886
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
