第17章 复制
内容
17.1 复制配置
17.2 复制实施
17.3 复制解决
17.4 复制注意和心得
复制可以使数据从mysql master 复制到一个或多个mysql slaves.
默认复制是异步的, 因此slaves没有必要永久的连接来接收从master的更新。
这意味着更新可以在远距离连接，即使在暂时性或间歇性连接如拨号服务。
依赖配置,
你可以复制所有的数据库,选择的数据库甚至是数据库里的某几个表
复制的优势包括:
1.扩展的解决方案 –分散负载到多个slave来改善性能。在这个环境下,所有的写和更新必须发生在master上,
读 发生在一个或者多个slaves上 这种模型可以改善写的性能(master 还专用于更新的)
同时极大地提高阅读速度在越来越多的slave.
2.数据安全 –因为数据被复制到了slave，slave可以暂停复制过程,可以用于备份在slave上
不需要破坏master相应的数据。
3.分析 –新鲜数据可以在master上产生,分析可以在slave上进行不会影响master的性能。
4.长距离的数据分布 –如果一个分支办公室需要一份主数据,你可以用复制来创建本地数据的拷贝
不需要直接访问master.
MySQL的复制功能支持单向的,异步复制,一个server 作为master，一个或者多个作为slaves.
这是和mysql Cluster 的同步复制有区别的。
在5.6版本里,一个接口半同步复制是支持的,除了内置异步复制支持。
在半同步复制里,一个commit 在master端执行blocks session，直到最少一个slave承认它接收到
登记了事务的信息。MySQL 5.6也支持延迟复制,比如 salve server 故意滞后 至少指定的时间
有许多可用放来来设置两台服务器之间的复制解决方案,
但是，使用最好的方法取决于数据和你所使用的引擎类型的存在
这里有2种核心类型的复制格式,语句级别的复制(SBR)，复制整个SQL语句,
和行级别的复制(RBR)，复制只改变的行。
你也可以使用第三种,混合模式
在MySQL 5.6,语句级别是默认的
mysql> SHOW VARIABLES like ‘binlog_format’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| binlog_format | MIXED |
+—————+——-+
1 row in set (0.00 sec)
- Statement
每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master
端执行过的相同的 SQL 再次执行。
优点：在 statement 模式下，首先就是解决了 row 模式的缺点，不需要记录每一行数据的变化，减少了 bin-log 日
志量，节省 I/O 以及存储资源，提高性能。因为他只需要记录在 master 上所执行的语句的细节，以及执行语句时候
的上下文的信息。
缺点：在 statement 模式下，由于他是记录的执行语句，所以，为了让这些语句在 slave 端也能正确执行，那么他还
必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在 slave 端杯执行的时候能够
得到和在 master 端执行时候相同的结果。另外就是，由于 MySQL 现在发展比较快，很多的新功能不断的加入，使
MySQL 的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug 也就越容易出现。在 statement 中，目
前已经发现的就有不少情况会造成 MySQL 的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的
时候会出现，比如：sleep() 函数在有些版本中就不能被正确复制，在存储过程中使用了 last_insert_id() 函数，可
能会使 slave 和 master 上得到不一致的 id 等等。由于 row 是基于每一行来记录的变化，所以不会出现类似的问题
。
3. Mixed
从官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持
row 复制。从 5.0 开始，MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出
现，给 MySQL Replication 又带来了更大的新挑战。另外，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除
Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据
执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的
statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修
改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是
update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。
一般推荐使用混合型:
MySQL 5.6.5 和以后的版本支持事务复制基于global transaction identifiers(GTIDs）
当使用这种复制类型的时候,它没有必要直接和binlog 或者文件的positions打交道。
简化了很多复制的任务。因为复制使用GTIDs时整个事务的,一致性在master和salve之间是当所有的事务在master上提
交后在slave上应用。
复制是有一些不同的选项和变量控制的,这些控制了复制的核心操作,
超时,数据库对应用的数据库和表进行过滤。
你可以使用复制来解决大量的不同的稳态i,包括性能问题,备份数据库,
缓建系统故障。
为了回答上面的问题,在当前的版本里,复制支持并行处理读,但是你要小心写。
然而,写了大多数应用系统的局限性。
你有2个站点,每个站点可以使位于它自己的server ，它有自己的CPU和MySQL 数据库。
在这种情况下，问题固有的是可靠性,浪费系统资源和缺乏灵活性
代替的是,你部署2个站点在2个server上。
如果你限制你的应用得当，你可以设置两个server 相互写,但我个人不建议你接受的局限性，因为它可以充满隐患。
除此之外,在很多应用中,负载的绝大多数是读，不是写。
你应用程序的语言是可能用于实现 数据库连接池到服务器应用线程。
使用这种模型, 你可以配置一个读的线程的池子在每个服务器上,来平衡读的请求
对于写,你需要配置你的连接在2个服务器上来使用Mysql Master进行写,
然后设置一个不同的连接池用于写 来使用slave database（当master挂了的时候).