一，集群
1，服务器的存储技术
DAS NAS SAN
2,集群类别
高性能计算集群HPC：通过以集群开发的并行应用程序，解决复杂的科学问题。
负载均衡（LB）集群：客户端访问负载可以在计算机集群中尽可能平均地分摊处理。
高可用（HA）集群：当集群中的一个系统发生故障时，集群软件迅速做出反应，将该系统的任务分配到集群中其它正在工作的系统上执行
3，lvs负载均衡方式
VS/NAT：通过网络地址转换实现的虚拟服务器。Director将用户请求报文的目的地址改成选定的Real Server地址后，转发给Real Server。大并发访问时，调度器的性能成为瓶颈。
VS/DR：直接使用路由技术实现虚拟服务器。通过改写请求报文的MAC地址，将请求发至RealServer，Real Server直接响应客户端。
VS/TUN：通过隧道方式实现虚拟服务器。Director采用隧道技术将请求发至Real Server后，Real Server直接响应客户端。
4，lvs 负载均衡的调度方式
轮询
加权轮询
最少连接数
加权最少连接数
目标地址散列
源地址散列
基于局部性的最少链接（Locality-Based Least Connections）
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
haproxy 工作模式
mode http：客户端请求被深度分析后再发往服务器。
mode tcp：在客户端与服务器这间建立全双工会话，不检查第七层信息。
mode health：仅做健康状态检查，已经不建议使用
HTTP Keep-alive事务模型的特点是什么
一次连接可以传输多个请求
客户端需要知道传输的内容的长度，避免长时间的等待
降低2个http事务的延迟
需要相对较少的服务器资源
HAProxy配置文件有哪些组成部分
default：为后续的其他部分设置缺省参数，缺省参数可以被后续部分重置；
frontend：描述集群接收客户端请求的信息集合；
backend：描述转发链接的后端服务器集合；
listen：把frontend和backend结合到一起的完整声明
NAT模式（VS‐NAT）
原理：就是把客户端发来的数据包的IP头的目的地址，在负载均衡器上换成其中一台RS的IP
地址，并发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包
的原IP地址改为自己的IP，将目的地址改为客户端IP地址即可｡期间,无论是进来的流量,还是
出去的流量,都必须经过负载均衡器｡
优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合
法的IP地址。
缺点：扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系
统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大
量的数据包都交汇在负载均衡器那，速度就会变慢
IP隧道模式（VS‐TUN）
原理：首先要知道，互联网上的大多Internet服务的请求包很短小，而应答包通常很大。那
么隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS,RS收到
后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡注
意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议｡所以,
在RS的内核中,必须编译支持IPTUNNEL这个选项
优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所
以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的
请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同
地域的分发。
缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP
Encapsulaon)协议，服务器可能只局限在部分Linux系统上
直接路由模式（VS-DR）
原理：负载均衡器和RS都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有RS对本
身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收
到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将
请求分发给这台RS｡这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返
给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡由于负载均衡
器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为
在同一台交换机上｡
优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法
返回给客户端。与VS‐TUN相比，VS‐DR这种实现方式不需要隧道结构，因此可以使用大多数
操作系统做为物理服务器。
缺点：（不能说缺点，只能说是不足）要求负载均衡器的网卡必须与物理网卡在一个物理段
上。
LVS 是 Linux Virtual Server ，Linux 虚拟服务器；是一个虚拟的服务器集群【多台机器
LB IP】。LVS 集群分为三层结构:
负载调度器(load balancer)：它是整个LVS 集群对外的前端机器，负责将client请求发送到
一组服务器[多台LB IP]上执行，而client端认为是返回来一个同一个IP【通常把这个IP 称为虚
拟IP/VIP】
服务器池(server pool)：一组真正执行client 请求的服务器，一般是我们的web服务器；除
了web，还有FTP，MAIL，DNS
共享存储(shared stored)：它为 server pool 提供了一个共享的存储区，很容易让服务器池
拥有相同的内容，提供相同的服务[不是很理解]
数据库 ：
进程myslqd 端口3306 默认数据库目录 /var/lib/mysql
默认的3个库叫 mysql test information_schema
不占磁盘的是information_schema 因为处于内存中
数据库的常见数据类型
数值类型：所用关键字为int、float
字符类型：所用关键字为char、varchar
日期时间类型：所用关键字为year、time、datetime
枚举类型：所用关键字为set、enum
索引的优点和缺点
索引的优点与缺点如下：
索引就像一本书的目录
加快查询记录的速度
会降低插入、更新记录的速度
默认情况下“表名.MYI” 文件保存表的索引信息
在表中创建外键字段要满足那些条件
在表中创建外键字段要满足以下条件：
表必须都使用innodb存储引擎
表中外键字段的类型要匹配
被参照字段要有明确的索引
MySQL体系结构的组成，并描述每个组成部分的作用。
参考答案
主要包括8个部分：
连接池：进程数限制、内存检查、缓存检查等。
SQL接口：用户通过sql客户端发过来的命令，由sql接口接收，sql操作(DML数据操作语言：
查询、修改、升级数据等；DDL数据定义语言：创建一个新的数据库、新的索引、删除一个
用户等；存储过程、视图触发器。
分析器： 分析查询语句 事务处理 对象访问权限。
优化器： 优化访问路径 、 生成执行树。
缓存和缓冲：保存sql查询结果。
存储引擎：用于管理存储的文件系统，将逻辑结构转换为物理结构的程序；不同的存储引擎
有不同的功能和存储方式。
管理工具：备份，恢复，安全，移植，集群等，这些工具一般和文件系统打交道，不需要和
mysql-server打交道，它们对应的都是命令。
物理存储设备(文件系统)
简述MySQL数据库访问的执行过程。
参考答案
1）客户端发出请求。
2）服务器端开辟线程响应客户端请求。
3）客户端发起sql语句查询数据库。
4）查询缓存：记录用户的sql查询语句，如果查询内容相同，直接从查询缓存回复。
5）如果缓存没有进入分析器。
6）分析器：分析用户命令语法是否正确，将用户的命令进行切片，一个词一个词用空格隔
开，获得用户要查询的表、内容、用户的权限等。
7）优化器：执行路径的选择，生成执行树。（每个SQL语句都有很多执行路径，优化的目的
就是在这些执行路径里选择最优的执行路径）。
8）存储引擎：用于管理存储的文件系统，不同的存储引擎有不同的功能和存储方式。
MySQL-MMM集群中可以有多少台主数据库服务器、多少台从数据库服务器？
参考答案
在MySQL-MMM环境中主数据库有且只能有2台，从数据库理论上可以任意多台
在MySQL-MMM集群中均衡模式和排他模式的作用是？
参考答案
均衡模式一般用于从数据库，可实现多个虚拟IP地址。
排他模式一般用于主数据库，只可设置一个虚拟IP地址
述mysqldump备份数据时数据库名的表示方式。
参考答案
--all-databases 所有库
数据库名 指定单个库
数据库名.表名 指定库里的指定表
-B 数据1 数据库2 备份多个库
集群的定义很多，通常认为集群
包含成员、消息、冗余和自动故障转移等功能，而复制仅仅是一个服务器向别一个服务器发送消息（数据）的方式。我们先讨论集群内部的复制（又称本地复制）
MySQL 集群的特点？
答案：为了实现最高性能。高可用性和冗余等目标。数据在集群内部的对等数据节点之间互
相复制。数据复制采用同步机制，每个数据节点到所有其他数据节点上，数据在多个数据节
点上存储。
MySQL 集群有一些创建高可用性系统的专用功能，主要包括？
答案：节点回复、日志、检查点、系统恢复、热备份恢复、无单点故障、故障转移、分区、联机操作
MySQL中myisam与innodb的区别，至少5点:
1>.InnoDB支持事物，而MyISAM不支持事物
2>.InnoDB支持行级锁，而MyISAM支持表级锁
3>.InnoDB支持MVCC, 而MyISAM不支持
4>.InnoDB支持外键，而MyISAM不支持
5>.InnoDB不支持全文索引，而MyISAM支持
mysql 20 个经典面试
1、MySQL的复制原理以及流程
基本原理流程，3个线程以及之间的关联；
首先主从都开启binlog日志，配置不t同的server-id
1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己relay log中；
3. 从：sql执行线程——执行relay log中的语句；
主将数据库的写改操作写入到自己的bin-log日志，
从同过io线程向主发起同步请求
主接收请求后使用dump线程向从的io线程发送同步信息，
从io线程接收到信息后写入自己的relay-log内，然后mysql线程读取relog日志没有同步的数据，写入到从库
2、MySQL中myisam与innodb的区别，至少5点
(1)、问5点不同；
1>.InnoDB支持事物，而MyISAM不支持事物
2>.InnoDB支持行级锁，而MyISAM支持表级锁
3>.InnoDB支持MVCC, 而MyISAM不支持
4>.InnoDB支持外键，而MyISAM不支持
5>.InnoDB不支持全文索引，而MyISAM支持
(2)、innodb引擎的4大特性
插入缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)
(3)、2者select count(*)哪个更快，为什么
myisam更快，因为myisam内部维护了一个计数器，可以直接调取
3、MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义
(1)、varchar与char的区别
char是一种固定长度的类型，varchar则是一种可变长度的类型
(2)、varchar(50)中50的涵义
最多存放50个字符，varchar(50)和(200)存储hello所占空间一样，但后者在排序时会消耗更多内存，因为order by col采用fixed_length计算col长度(memory引擎也一样)
(3)、int（20）中20的涵义
是指显示字符的长度
但要加参数的，最大为255，比如它是记录行数的id,插入10笔资料，它就显示00000000001 ~~~00000000010，当字符的位数超过11,它也只显示11位，如果你没有加那个让它未满11位就前面加0的参数，它不会在前面加0
20表示最大显示宽度为20，但仍占4字节存储，存储范围不变；
(4)、mysql为什么这么设计
4、问了innodb的事务与日志的实现方式
(1)、有多少种日志；
错误日志：记录出错信息，也记录一些警告信息或者正确的信息。
查询日志：记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。
慢查询日志：设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。
二进制日志：记录对数据库执行更改的所有操作。
中继日志：
事务日志：
(2)、事物的4种隔离级别
事务的基本要素（ACID）
1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。
3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。
隔离级别
读未提交(RU)
读已提交(RC)
可重复读(RR)
串行
1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。
3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。
小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表
(3)、事务是如何通过日志来实现的，说得越深入越好。
事务日志是通过redo和innodb的存储引擎日志缓冲（Innodb log buffer）来实现的，当开始一个事务的时候，会记录该事务的lsn(log sequence number)号; 当事务执行时，会往InnoDB存储引擎的日志
的日志缓存里面插入事务日志；当事务提交时，必须将存储引擎的日志缓冲写入磁盘（通过innodb_flush_log_at_trx_commit来控制），也就是写数据前，需要先写日志。这种方式称为“预写日志方式”
5、问了MySQL binlog的几种日志录入格式以及区别
(1)、binlog的日志格式的种类和分别
(2)、适用场景；
(3)、结合第一个问题，每一种日志格式在复制中的优劣。
Statement：每一条会修改数据的sql都会记录在binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能 与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条 件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所 产生的日志量会增加多少，以及带来的IO性能问题。)
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的 一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).
使用以下函数的语句也无法被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁
2.Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下 每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
3.Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择 一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的 变更。
6、问了下MySQL数据库cpu飙升到500%的话他怎么处理？
(1)、没有经验的，可以不问；
(2)、有经验的，问他们的处理思路。
列出所有进程 show processlist 观察所有进程 多秒没有状态变化的(干掉)
查看超时日志或者错误日志 (做了几年开发,一般会是查询以及大批量的插入会导致cpu与i/o上涨,,,,当然不排除网络状态突然断了,,导致一个请求服务器只接受到一半，比如where子句或分页子句没有发送,,当然的一次被坑经历)
7、sql优化
(1)、explain出来的各种item的意义；
select_type
表示查询中每个select子句的类型
type
表示MySQL在表中找到所需行的方式，又称“访问类型”
possible_keys
指出MySQL能使用哪个索引在表中找到行，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用
key
显示MySQL在查询中实际使用的索引，若没有使用索引，显示为NULL
key_len
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度
ref
表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
Extra
包含不适合在其他列中显示但十分重要的额外信息
(2)、profile的意义以及使用场景；
查询到 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 Systemlock, Table lock 花多少时间等等
8、备份计划，mysqldump以及xtranbackup的实现原理
全量备份
增量备份：每一次备份相对于上一次的备份后的增加和修改
差量备份：每一次备份相对于上一次的全量备份之后所做的增减和修改
(1)、备份计划；
(2)、备份恢复时间；
这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考
20G的2分钟（mysqldump）
80G的30分钟(mysqldump)
111G的30分钟（mysqldump)
288G的3小时（xtra)
3T的4小时（xtra)
逻辑导入时间一般是备份时间的5倍以上
(3)、xtrabackup实现原理
在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。
9、mysqldump中备份出来的sql，如果我想sql文件中，一行只有一个insert....value()的话，怎么办？如果备份需要带上master的复制点信息怎么办？
--skip-extended-insert
[root@helei-zhuanshu ~]# mysqldump -uroot -p helei --skip-extended-insert
10、500台db，在最快时间之内重启
puppet，dsh
11、innodb的读写参数优化
(1)、读取参数
global buffer pool以及 local buffer；
(2)、写入参数；
innodb_flush_log_at_trx_commit
innodb_buffer_pool_size
(3)、与IO相关的参数；
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 0
(4)、缓存参数以及缓存的适用场景。
query cache/query_cache_type
并不是所有表都适合使用query cache。造成query cache失效的原因主要是相应的table发生了变更
第一个：读操作多的话看看比例，简单来说，如果是用户清单表，或者说是数据比例比较固定，比如说商品列表，是可以打开的，前提是这些库比较集中，数据库中的实务比较小。
第二个：我们“行骗”的时候，比如说我们竞标的时候压测，把query cache打开，还是能收到qps激增的效果，当然前提示前端的连接池什么的都配置一样。大部分情况下如果写入的居多，访问量并不多，那么就不要打开，例如社交网站的，10%的人产生内容，其余的90%都在消费，打开还是效果很好的，但是你如果是qq消息，或者聊天，那就很要命。
第三个：小网站或者没有高并发的无所谓，高并发下，会看到 很多 qcache 锁 等待，所以一般高并发下，不建议打开query cache
12、你是如何监控你们的数据库的？你们的慢日志都是怎么查询的？
监控的工具有很多，例如zabbix，lepus，我这里用的是lepus
13、你是否做过主从一致性校验，如果有，怎么做的，如果没有，你打算怎么做？
主从一致性校验有多种工具 例如checksum、mysqldiff、pt-table-checksum等
14、你们数据库是否支持emoji表情，如果不支持，如何操作？
如果是utf8字符集的话，需要升级至utf8_mb4方可支持
15、你是如何维护数据库的数据字典的?
这个大家维护的方法都不同，我一般是直接在生产库进行注释，利用工具导出成excel方便流通
16、你们是否有开发规范，如果有，如何执行的
17、表中有大字段X(例如：text类型)，且字段X不会经常更新，以读为为主，请问
(1)、您是选择拆成子表，还是继续放一起；
(2)、写出您这样选择的理由。
答：拆带来的问题：连接消耗 + 存储拆分空间；不拆可能带来的问题：查询性能；
如果能容忍拆分带来的空间问题,拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区) 顺序IO,减少连接消耗,最后这是一个文本列再加上一个全文索引来尽量抵消连接消耗
如果能容忍不拆分带来的查询性能损失的话:上面的方案在某个极致条件下肯定会出现问题,那么不拆就是最好的选择
18、MySQL中InnoDB引擎的行锁是通过加在什么上完成(或称实现)的？为什么是这样子的？
.InnoDB是基于索引来完成行锁
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列,
如果 id 不是索引键那么InnoDB将完成表锁,,并发将无从谈起
19、如何从mysqldump产生的全库备份中只恢复某一个库、某一张表？
如何只恢复某个库
全库备份
[root@HE1 ~]# mysqldump -uroot -p --single-transaction -A --master-data=2 >dump.sql
只还原erp库的内容
[root@HE1 ~]# mysql -uroot -pMANAGER erp --one-database <dump.sql
参数是--one-database简写-o的参数
从全库备份中抽取出t表的表结构
[root@HE1 ~]# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `t`/!d;q' dump.sql
从全库备份中抽取出t表的内容
[root@HE1 ~]# grep'INSERT INTO `t`' dump.sql
开放性问题：据说是腾讯的
一个6亿的表a，一个3亿的表b，通过外间tid关联，你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。
1、如果A表TID是自增长,并且是连续的,B表的ID为索引
select * from a,b where a.tid = b.id and a.tid>500000 limit 200;
2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。
select * from b , (select tid from a limit 50000,200) a where b.id = a .tid;
读写分离
MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理
是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查
询导致的变更同步到集群中的从数据库。 当然，主服务器也可以提供查询服务。使用读写
分离最大的作用无非是环境服务器压力
读写分离的好处
1.增加冗余
2.增加了机器的处理能力
3.对于读操作为主的应用，使用读写分离是最好的场景，因为可以确保写的服务器压力更
小，而读又可以接受点时间上的延迟
读写分离提高性能的原因
主从只负责各自的写和读，极大程度的缓解X锁和S锁争用
读写分离适用与读远大于写的场景，如果只有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能不高。 对于写和读比例相近的应用，应该部署双主相互复制
MySQL复制另外一大功能是增加冗余，提高可用性，当一台数据库服务器宕机后能通过调
整另外一台从库来以最快的速度恢复服务，因此不能光看性能，也就是说1主1从也是可以
的
mysqldump以及xtranbackup的实现原理；备份恢复时间；备份恢复失败如何处理
mysqldump是采用sql级别的备份机制，将数据表导成sql脚本文件，在不用的mysql版本之间
升级时相对比较合适。
xtranbackup是innodb的hotbackup工具，xtrbackup在启动的时候会复制所有的数据文件，
同时会启动一个后台进程，用于监视事务日志，并且从事务日志复制最新的修改。所以
xtrbackup在启动的开始，就不懂的将事务日志的每个数据文件的修改都记录下来。
mysqldump的备份和恢复时间都很慢，任何数据的更新和变化都会被挂起。
xtrabackup的恢复时间比mysqldump快一点，但是会锁表。
备份恢复失败的话，其实原因很多，主要可能就是参数设置的不对，检查一下参数。
【评析】使用mysqldump备份数据表的命令，在shell下执行：
mysqldump -u用户名 -p密码（可以直接-p） -h主机名 --databases 数据库名 > 要备份的
文件路径
mysqldump -u用户名 -p密码 -h主机名 --all-databases >要备份的文件路径
mysqldump -u用户名 -p密码 -h主机名 --no-data 数据库名 >要备份的文件路径
InnoDB的行锁是通过加在索引上实现的
MySQL 数据库备份方式
增量备份、差异备份、完整备份
分为同步复制和异步复制，实际复制架构中大部分为异步复制。
复制的基本过程如下：
1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最
开始的日志）之后的日志内容；
2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息
读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包
含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的
位置；
3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relaylog文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文
件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置
开始往后的日志内容，请发给我”；
4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容
成为在Master端真实执行时候的那些可执行的内容，并在自身执行。