此专题题目较多,因此分为上下两部分来讲,此为上篇。
完整版题库请到我的资源中下载,此为传送门。https://download.csdn.net/download/kanon_lgt/85010419?spm=1001.2014.3001.5503
讲解:
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中记录了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正确。
讲解:
先看题目,要求导出以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了。
讲解:
这道题出得非常妙,请道友们一定仔细琢磨明白,关系到你今后删库是否需要跑路的问题。
看题目:
题目描述,你这次又手残或者脑残了,而且比上次还残,上次你做了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,要求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主从同步安全包括以下三点:
- 主从同步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正确。
讲解
看题目:
有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正确。
讲解
看题目:
此题很多关键信息隐含在题目描述中,影响对答案的选择,
- 一个严谨的科学的数据收集应用使用了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正确。
讲解
异步主从复制,包括半同步复制,其master上的binlog作用都是记录master的写事务日志并传递给slave进行replay。
master的binlog是slave主动拉取的。
因此,选项AE正确。
讲解
在什么情况下,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
原创文章,转载请注明来源。