Mysql扩展之replication概述

闲来无事，平时Oracle用的多，想看看mysql的一些知识，每天总结一下：

mysql在互联网领域用的如此广泛很大一部分原因是是源于它的replication机制，简单实用，几台PC机子，很容易提高性能，乃中小网站必备良方。

首先什么情况下要扩展数据库，建个网站，建个数据库，某一天网站火了，访问量暴增，意味着从你服务器上读网页的连接多了，IO瓶颈来了，自然想多加几台机子来分担压力，但是数据还要跟源主机上的数据库内数据保持一致，这时候就是开始扩展数据库的时候，replication就开始派上用场了。

replication的实现机制

第一步是master必须打开Binary Log日志，里面包含了数据库的各种操作记录，slave通过IO线程连上master主机，并请求日志内容，这个请求应该还包括日志的请求位置，即从什么位置开始的日志。

第二步master收到请求后就开始通过IO线程给slave返回内容，返回的内容除了日志内容外还应该包括日志文件的位置以及下次从什么地方开始获取新日志。

第三步就是slave的IO线程将所得到的内容记录到本机的Relay Log文件中，位置内容则记录在master-info文件中，以便下次能快速定位master的日志内容。

第四步就是slave解析这些日志内容然后执行，这样master与slave数据就同步完成。

值得注意的是第三步与第四步是同时执行的（早期的mysql是分开执行的），是有两个线程（IO线程与SQL线程）异步执行的，这样的好处无非是减少同步时间，拿空间换时间，减少了数据丢失的概率。

这是一台master机子与一台slave机子的通信过程。

而实际运用中显然不可能只有一台slave，主要有一下几种集群方式。

master-slaves

一台master对多台slaves,这个是最简单的集群方式，原理与上面的相同

master-master

两台master，这种架构主要是为了解决热备问题，可以防止master宕机导致需要重新部署slaves，这里有个问题，就是两台master就意味着两边都要提供读写功能，实际操作中应该避免同一张表在master两边都提供写的功能，这样会导致脏数据，应该是一部分表在master1端写，一部分表在master2端写。

master-slaves-slaves（级联复制架构）

这中架构目的也很明确，普通的master-salves架构当slaves机子越来越多的时候，连接到master机子上的IO线程就多了，master又要对外提供写入服务，压力太大，这种架构就是给master减压，将IO转移给slaves，然后slaves再给第二级slaves提供IO服务，坏处自然也很明显，延时严重。

master-master-slaves-slaves

这种最复杂，也最安全，最稳定，等于是将第二种与第三种组合起来。

以上几种为常用的垂直扩展架构，主要解决的是大规模并发读的问题，至于并发写入，则要用到mysql的数据切分，明天再写。