1. MySQL master-slave replication
Heterogeneous file will be the main MySQL database replication technology from using scp / rsync commands similar level replication, remote data is transmitted, but the MySQL master-slave replication technology is carried by its own software functionality, without the aid of a third party tools, and, MySQL master-slave replication is not a direct copy of the database files on disk, but will send logical record of database updates binlog log into the database server requires local synchronization, and then by a local database thread reads log SQL statement and re-apply to the MySQL database, which can be realized from the master database replication.
1. MySQL master-slave replication Introduction
MySQL database support for the main one-way, two-way, cascaded chain, a ring, such as different business scenarios from the copy. During replication, a server (Example) as a main database (Master). Receiving from the user, updates its contents, while one or more other servers as the server from (the Slave), the primary server receives the content from the log file binlog, then the contents of the log parsed SQL statements to reapply from the other server, so that the main achieve the same data from the server.
If the chain cascading replication, then, from outside the server in addition to being, as will also the underlying database server from the primary server from the server itself. Copy form similar chain cascade A ==> B ==> C.
The following two logic diagram from the copy schema, the schema data is written only in the Master unidirectional main server.
The following main bidirectional replication master logic chart, this architecture can perform data writing Master server 1 side or the second end Master server, or at both ends of the write data (require special settings).
The following is a linear cascade unidirectional twin master copy logic architecture diagram, this architecture can perform data writing Master server 1 side, the working scene Matser Master server 1 and server 2 as the primary master mutual support, as the Slave 1 from the library server, Master intermediate server 2 require special settings.
以下为环状级联单向多主同步逻辑架构图，任意一个点都可以写入数据，此架构比较复杂，属于极端环境下的“作品”，一般场景应慎用。
在当前的生产环境中，MySQL主从复制默认都是异步的复制方式，即不是严格实时的数据同步，但是在正常
情况下带给用户的体验几乎都是实时的。
2. MySQL主从复制企业级应用场景
MySQL主从复制集群技术使得MySQL数据库支持大规模高并发的读写操作成为可能，同时又能有效地解决物理服务器宕机场景的数据备份和进行快速业务切换的问题。对于企业生产环境来说，MySQL主从复制主要有以下几个重要的应用场景。
1. 从服务器作为主服务器的实时数据备份
主从服务器架构的设计，可以大大加强MySQL数据库架构的健壮性。例如，当主服务器出现问题时，我们可以人工切换或设置成自动切换到从服务器继续提供服务，此时从服务器的数据和宕机时的主数据库几乎是一致的。
利用MySQL的主从复制技术进行数据备份，在硬件故障、软件故障、人为在数据库外误操作的场景下，该数据备份是有效的；但对于人为地在数据库中执行drop、delete等语句删除数据库的情况，从库的备份功能就没有用了，因为从服务器也会执行删除的语句。
2. 主从服务器实现读写分离，从服务器实现负载均衡
MySQL主从服务器架构可通过程序（PHP、Java等）或代理软件（maxscale、atlas）实现对用户（客户端）的请求按读和写进行分离访问，即让从服务器仅仅处理用户的select（查询）请求，以降低用户查询的响应时间及同时在主服务器上读写所带来的访问压力。对于更新的数据（例如update、insert、delete语句）仍然会交给主服务器处理，以确保主服务器和从服务器保持实时同步。
百度、淘宝、新浪等绝大多数的网站都是用户浏览的页面多于用户发布内容的页面，因此通过在从服务器上接收只读请求，就可以很好地减轻主库的读压力，且从服务器可以很容易地扩展为多台，使用LVS进行负载均衡（读写分离软件自身大多也有负载均衡的功能），效果就非常棒了，这就是数据库的读写分离架构。
3. 根据业务重要性对多个从服务器进行拆分访问
根据公司的业务，可以对几个不同的从服务器进行拆分。例如，有为外部用户提供浏览查询服务的从服务器，有内部DBA用来进行数据备份的从服务器，还有为公司内部人员提供访问的后台、脚本、财务统计、日志分析及供开发人员查询使用的从服务器。这样的拆分除了能够减轻主服务器的压力之外，还可以使得数据库对外部用户浏览、内部用户业务处理及DBA的备份操作等互不影响。具体如何对从服务器进行拆分可以用下面的简单架构来说明：
3. MySQL主从读写分离实现方案
（1）通过程序实现读写分离（需要程序支持）
PHP和Java程序都可以通过设置多个连接文件轻松地实现对数据库的读写分离，即当语句关键字为select时，就去连接读库的连接文件，若为update、insert、delete时，则连接写库的连接文件。
通过程序实现读写分离的缺点就是需要开发人员对程序进行改造，程序本身无法直接支持读写分离。
（2）通过开源的软件实现读写分离
Maxscale、Atlas、Mycat等代理软件也可以实现读写分离的功能，并且无须对应用程序做任何修改，而且它们还支持负载均衡等功能；缺点是又引入了单点服务，并且稳定性不如程序实现好。
（3）大型门户独立开发DAL层综合软件
百度、阿里等大型门户都有开发牛人，会花大力气开发适合自己业务的读写分离、负载均衡、监控报警、自动扩容、自动收缩等一系列功能的DAL层软件。
MySQL读写分离的基本逻辑图如下图所示：
4. MySQL主从复制原理
MySQL主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个MySQL数据库（Master）复制到另一个MySQL数据库（Slave），在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程（SQL线程和IO线程）在Slave端，另外一个线程（binlog dump线程）在Master端（MySQL 5.6起SQL线程可以是多个）。
要实现MySQL的主从复制功能，首先必须打开Master端的binlog日志功能。因为整个复制过程实际上就是Slave从Master端获取binlog日志，然后再在Slave上以相同的顺序执行获取的binlog日志中所记录的各种SQL操作，从而实现主从数据一致的功能。
[mysqld]
log_bin = /application/mysql/logs/oldboy-bin ---路径/application/mysql/logs/要提前创建，路径非必须，其中oldboy-bin是binlog日志的前缀
5. MySQL主从复制原理及过程
1）在Slave服务器上执行start slave命令开启主从复制开关，主从复制开始进行。
2）此时，Slave服务器的I/O线程会通过在Master上已经授权的复制用户权限请求连接Master服务器，并请求从指定binlog日志文件的指定位置之后开始发送binlog日志内容。
3）Master服务器接收到来自Slave服务器的I/O线程的请求之后，其上负责复制的binlog dump线程会根据Slave服务器的I/O线程请求的信息，分批读取指定binlog日志文件所指定位置之后的binlog日志信息，然后返回给Slave端的I/O线程。返回的信息中除了binlog日志内容之外，还包括在Master服务器端记录的新的binlog文件名称，以及在新的binlog中的下一个指定的更新位置。
4）当Slave服务器的I/O线程获取到Master服务器上I/O线程发送的日志内容及日志文件和位置点之后，会将binlog日志内容依次写入到Slave端自身的Relay Log（即中继日志）文件（MySQL-relay-bin.xxxxxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取Master端新binlog日志时，能够告诉Master服务器需要从新binlog日志的指定文件及位置开始请求新的binlog日志内容。
5）Slave服务器端的SQL线程会实时地检测本地Relay Log中I/O线程新增加的日志内容，然后及时地把Relay Log文件中的内容解析成SQL语句，并在自身Slave服务器上按解析SQL语句的位置顺序执行和应用这些SQL语句，并将当前应用中继日志的文件名及位置点记录在relay-log.info中。
小结：
- 主从复制是异步的逻辑的SQL语句级的复制
- When copying, main library has a binlog dump thread, there are two threads from the library, I / O threads and SQL thread
- From MySQL 5.6 onwards, Slave server SQL thread may be a number
- Master-slave replication is a necessary condition for the main library function to open records binlog
- all MySQL server-id node configuration can not be the same for replication
- binlog file only records to the database SQL statements have changed, does not record any inquiries and statement did not make changes to the database
Reproduced in: https: //www.jianshu.com/p/9c93ba194b9d