5.1.1 下面对 Linux 下 mysqldump 备份命令及参数描述正确的是( A )
A.mysqldump -h ip -u -p DBNAME>back.sql
B.mysqldump -P ip -h DBNAME>back.sql
C.mysqldump -u ip -P DBNAME>back.sql
D.mysqldump -h ip -u DBNAME>back.sql
5.1.2 如何将 MySQL 数据库中的 mail 这个数据库备份成 mail.sql? ( B )
A、mysql -opt mail uroot-p > mail sql
B、mysqldump --opt mail -uroot -p > mail.sql
C、mysql -uroot -p > mail.sql
D.mysql -uroot -p < mail sql
5.1.3 MySQL 主从结构的主数据库中不可能出现以下哪种日志? ( C )
5.1.4 对于数据库备份正确的做法是：( D )
5.2.1 如何用 mysql 命令进行备份和恢复?以 Lest 库为例，创建一个备份，并再用此备份进行恢复
mysqldump -uroot -p123456 –B Lest > lest.sql
source /backup/lest.sql
5.2.2 Mysql 备份工具__mysqldump__xtrabackup__
5.3.1 每天凌晨 2 点对 mfdata 数据库进行备份，备份到/data/mysql/下，并以时间为备份名。
Mysqldump –uroot –p123 –B mfdata >/data/mysql/mfdata_ $(date +%F).sql
mysqldump -uroot -p -S /tmp/mysql.sock
mysqldump -uroot -p -h 10.0.0.51 -P3306
5.3.3 说明一下 mysql 主从复制原理并描述一下部署主从复制的步骤
1.change master to 时，ip pot user password binlog position 写入到 master.info 进行记录
2. start slave 时，从库会启动 IO 线程和 SQL 线程
3.IO_T，读取 master.info 信息，获取主库信息连接主库
4. 主库会生成一个准备 binlog DUMP 线程，来响应从库
5. IO_T 根据 master.info 记录的 binlog 文件名和 position 号，请求主库 DUMP 最新日志
6. DUMP 线程检查主库的 binlog 日志，如果有新的，TP(传送)给从从库的 IO_T
7. IO_T 将收到的日志存储到了 TCP/IP 缓存，立即返回 ACK 给主库 ，主库工作完成
8.IO_T 将缓存中的数据，存储到 relay-log 日志文件,更新 master.info 文件 binlog 文件名和 postion，IO_T 工作完成
9.SQL_T 读取 relay-log.info 文件，获取到上次执行到的 relay-log 的位置，作为起点，回放 relay-log
10.SQL_T 回放完成之后，会更新 relay-log.info 文件。
mysqldump -u username -p -all-databases > BackupName.sql
5.3.5 对 mysql 数据库 test 进行备份和恢复
mysqldump -uroot -p123456 -P3306 test -t > 0106.sql
create database test
source /backup/0106.sql
5.3.6 如何备份某个库，某个库下的某个表，某个库排除某个表
mysqldump -u username -p dbname table1 table2 ...-> BackupName.sql
table1 和 table2 参数表示需要备份的表的名称，为空则整个数据库备份;
BackupName.sql 参数表设计备份文件的名称，文件名前面可以加上一个绝对路径。通常将数据库
分成一个后缀名为 sql 的文件;
--ignore-table 选项 mysqldump 备份数据库时忽略某个表
1 mysql -u root -p [dbname] < backup.sq
2 还原直接复制目录的备份 通过这种方式还原时，必须保证两个 MySQL 数据库的版本号是相同
的。
MyISAM 类型的表有效，对于 InnoDB 类型的表不可用，InnoDB 表的表空间不能直接复制。
5.3.8 主从概念，如何配置，管理，监控，有确定。主从如何同步的?
1.change master to 时，ip pot user password binlog position 写入到 master.info 进行记录
2. start slave 时，从库会启动 IO 线程和 SQL 线程
3.IO_T，读取 master.info 信息，获取主库信息连接主库
4. 主库会生成一个准备 binlog DUMP 线程，来响应从库
5. IO_T 根据 master.info 记录的 binlog 文件名和 position 号，请求主库 DUMP 最新日志
6. DUMP 线程检查主库的 binlog 日志，如果有新的，TP(传送)给从从库的 IO_T
7. IO_T 将收到的日志存储到了 TCP/IP 缓存，立即返回 ACK 给主库 ，主库工作完成
8.IO_T 将缓存中的数据，存储到 relay-log 日志文件,更新 master.info 文件 binlog 文件名和 postion，IO_T 工作完成
9.SQL_T 读取 relay-log.info 文件，获取到上次执行到的 relay-log 的位置，作为起点，回放 relay-log
10.SQL_T 回放完成之后，会更新 relay-log.info 文件。
2)Slave 机器的 IO 和 SQL 状态都必须为 YES，缺一不可;
5.3.9 msyql 备份命令?mysql 如何给 jfedu 用户对所有表授权访问，密码为 jfedu.net
mysqldump -h localhost -u root -p jacken > /data/jacken.db
mysql> grant all privileges on *.* to jfedu@localhost identified by "jfedu.net";
5.3.10 如何判断 mysql 主从是否同步?该如何使其同步?
mysql> show slave status\G #查看是否都为 yes
Slave_IO_Running
Slave_SQL_Running
5.3.11 mysql 的 innodb 如何定位锁问题，mysql 如何减少主从复制延迟
show status like 'innodb_rows_lock%'
select * from information_schema.innodb_trx;
select * from sys.innodb_lock_waits;
select * from performance_schema.threads;
select * from performance_schema.events_statements_current;
select * from performance_schema.events_statements_history;
每次事务提交都立即刷新 binlog 到磁盘(双一标准中的其一)
每次事务提交不立即写入磁盘,靠操作系统判断什么时候写入
2 dump 线程多导致的，系统资源压力大，由于传送日志是串行的。
由于超大事务存在，由于是串行工作，会阻塞后续其他事务的传送。
group commit (需要配合 GTID 来实现的)
业务的分离和分布式(Mycat,InnoDB Cluster)
4 SQL 线程慢(Classic replication 传统) *****
从库 默认只有一个 SQL 线程,串行回放事务。在主库有并发事务量大，或者有超大事务时，都会导致 SQL 延时较严重。
5.6 版本，加入了 GTID 特性，所以支持了并发 SQL 特性，基于不同库实现并行回放事务
5.7 版本，GTID 功能进行了升级，可以通过 Logical_clock 模式，实现事务级别的多 SQL 线程的回放。我们把这种复制模式叫做 MTS。
写出对 MySQL 数据库 test 进行备份和恢复的命令
mysqldump -uroot -p123456 -P3306 test -t > 0106.sql
create database test
source /backup/0106.sql
5.3.12 Mysql 的 binlog 格式有哪些，默认的是什么格式，格式选取的标准是什么?
binlog 有三种格式：Statement、Row 以及 Mixed。
–基于 SQL 语句的复制(statement-based replication,SBR)，
–基于行的复制(row-based replication,RBR)，
–混合模式复制(mixed-based replication,MBR)。
每一条会修改数据的 sql 语句会记录到 binlog 中。优点是并不需要记录每一条 sql 语句和每一行的数据变化，减少了 binlog 日志量，节约 IO，提高性能。缺点是在某些情况下会导致 master-slave 中的数据不一致(如 sleep()函数， last_insert_id()，以及 user-defined functions(udf)等会出现问题)
不记录每条 sql 语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或 function、或 trigger 的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是 alter table 的时候会让日志暴涨。
以上两种模式的混合使用，一般的复制使用 STATEMENT 模式保存 binlog，对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog，MySQL 会根据执行的 SQL 语句选择日志保存方式。
5.3.13 Mysql 主从是否同步，要在主库上查看还是从库上查看，主要关注哪些参数?
show slave status\G #查看是否都为 yes
Slave_IO_Running
Slave_SQL_Running
5.3.14 说明一下目前线上 mysql 集群 的部署方案
MHA+atlas
Mycat+MGR
InnoDB cluster
PXC
MGC
5.3.15 用哪个命令可以对 Mysql 中的数据库进行备份?
mysqldump -u 用户名 -p 密码 --databases 数据库 1 数据库 2 > xxx.sql
--all-databases, -A：备份所有数据库
--databases, -B: 用于备份多个数据库，如果没有该选项,mysqldump 把第一个名字参数作为数据库名，后面的作为表名。使用该选项，mysqldum 把每个名字都当作为数据库名。
5.3.16 mysql 的 binlog 有几种，区别是什么?mysql 双主复制原理是什么?有什么优点和缺点?mysql 如何进行增量备份?
binlog 的格式也有三种：STATEMENT、ROW、MIXED 。
1、STATMENT 模式：基于 SQL 语句的复制(statement-based replication, SBR)，每一条会修改数据的sql 语句会记录到 binlog 中。
2、基于行的复制(row-based replication, RBR)：不记录每一条 SQL 语句的上下文信息，仅需记录哪条数据被修改了，修改成了什么样子了。
3、混合模式复制(mixed-based replication, MBR)：以上两种模式的混合使用，一般的复制使用STATEMENT 模式保存 binlog，对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存binlog，MySQL 会根据执行的 SQL 语句选择日志保存方式。
双向的主从复制，也就是互为对方的从服务器，每台服务器即是对方的主服务器，又是对方的从服务器。
1:主服务器凡运行语句,都产生一个二进制日志 binlog
3:从主服务读取到的 binlog,转换为自身可执行的 relaylog,
5.3.17 简述数据库中全量备份、差异备份、事务日志备份的恢复方式
mysql -hhostname -uusername -ppassword databasename < backupfile.sql
mysqlbinlog -d test mysql-bin.000003 >003bin.sql
5.3.18 SAN 方式高可用，你对这方面有了解吗?
SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，
共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操
作，
如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动 MySQL。
5.3.19 mysqldump 实现不锁表的参数
mysqldump 备份不锁表：加上--lock-tables=false 参数，
如果是 innodb，则加上--single-transcation 比较好。
5.3.21 MySQL 的同步、半同步、一步同步主从复制有什么区别?
异步复制，主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。
全同步复制，当主库提交事务之后，所有的从库节点必须收到、APPLY 并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。
半同步复制，是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。
5.3.22 对于一个数据量较多的系统(数据库 10T，每天归档 500g)，您如何设计备份策略
每周 Full，每天 inc，或使用 DG、OGG
5.3.23 对于 exp/imp 和 impdb/expdp 逻辑备份的时候，有什么方法提高效率
expdp/impdp 是服务端程序，影响它速度的只有磁盘 IO。
exp/imp 可以在服务端，也可以在客户端。所以，它受限于网络和磁盘
采用 direct path 可以提高导出速度。所以，在使用 exp 时，就可以采用直接路径模式。这种模式有 2 个相关的参数：
DIRECT 和 RECORDLENGTH 参数。
DIRECT 参数定义了导出是使用直接路径方式(DIRECT=Y)，还是常规路径方式(DIRECT=N)。常规路径导出使用 SQL SELECT语句从表中抽取数据，直接路径导出则是将数据直接从磁盘读到 PGA 再原样写入导出文件，从而避免了 SQL 命令处理层的数据转换过程，大大提高了导出效率。在数据量大的情况下，直接路径导出的效率优势更为明显，可比常规方法速度提高三倍之多。
和 DIRECT=Y 配合使用的是 RECORDLENGTH 参数，它定义了 Export I/O 缓冲的大小，作用类似于常规路径导出使用的BUFFER 参数。建议设置 RECORDLENGTH 参数为最大 I/O 缓冲，即 65535(64kb)。其用法如下：
exp userid=system/manager full=y direct=y recordlength=65535 file=exp_full.dmp log=exp_full.log
老男孩IT教育开设有全日制脱产班、周末班和网络在线班，以不同形式帮助更多有需要的盆友们提升技能。了解更多课程及公开课内容，可点击本文左下方“阅读原文”~
