Question

mysql读写分离原理是什么

假设我现在有一个WEB程序，有两个mysql数据库服务器，就叫A,B吧，A主，B从，如何实现读写分离？
1，在读写这两个操作中，web程序在写的时候就找A，读的时候找B，还是web程序发一样的指令，由数据库判断谁负责写，谁负责读？
2，在只有两个mysql服务器情况下，A只负责写，性能肯定会好，但是B事实上读写都要，B在读操作时，性能上有没有得到优化？
3，假设有N个从数据库，主数据库的数据如何同步到N个从数据库中，是向N个从数据库发送n次，还是只发一次，让N个从数据库之间自己同步？

Answer 1

利用mysql proxy来实现的。

MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 当然，主服务器也可以提供查询服务。使用读写分离最大的作用无非是环境服务器压力。

Answer 2

读写分离就是利用mysql的主从复制完成的，A不间断的把binlog信息发送给B，保持B和A的数据一致，如果还需要在B上写的话，你需要开启主主模式。关于第三点，你如果采取的是A-B A-C A-D模式的话肯定是需要A给每个从库都需要发送binlog信息的，如果是A-B-C这种级联的模式，是只需要A给B发送一次binlog信息，然后B给C发一次。

Answer 3

Asynchronous Replication Automatic failover

其原理是在一条异步复制通道上配置多个可用复制源，当某个复制源不可用时（宕机、复制链路中断），且 slave 的 IO 线程尝试重连无效，自动根据权重选择新的源继续同步。

• 准备一个 MGR 集群和单实例，模拟复制链路切换，当 primary 故障，slave 自动切换到其他节点。dbdeployer deploy replication --topology=group 8.0.22 --single-primarydbdeployer deploy single 8.0.22

2. 在从机上建立指向 MGR 主节点的复制通道，


• change master to master_user='msandbox',master_password='msandbox', master_host='127.0.0.1',master_auto_position=1,source_connection_auto_failover=1,master_port=23223,master_retry_count=6,master_connect_retry=10 for channel 'mgr-single';

• 在 master_retry_count 和 master_connect_retry 的设置上要考虑尝试重连多久才切换复制源。

3. 在从机上配置 asynchronous connection auto failover

• 配置 asynchronous connection auto failover 的两个函数：

• asynchronous_connection_failover_add_source(channel-name,host,port,network-namespace,weight)

• asynchronous_connection_failover_delete_source(channel-name,host,port,network-namespace)

• 权重值大的被优先级选择，可以配合MGR的选举权重配置 asynchronous_connection_failover 的权重。当 MGR 节点切换，异步复制也能切换到新的主节点。

• SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23223,null,100); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23224,null,80); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23225,null,50);start slave for channel 'mgr-single';




4. 检查异步复制通道是否启用 failover。


mysql> SELECT CHANNEL_NAME, SOURCE_CONNECTION_AUTO_FAILOVER FROM performance_schema.replication_connection_configuration; +--------------+---------------------------------+| CHANNEL_NAME | SOURCE_CONNECTION_AUTO_FAILOVER |+--------------+---------------------------------+| mgr-single   |  1                              |+--------------+---------------------------------+1 row in set (0.01 sec





5. 把 MGR 的 primary 节点 kill 掉，这个从节点会在尝试几轮重连失败后自动切换到次权重的复制源，其日志中会输出切换信息。

注意：当主节点故障，一旦复制链路成功 failover 后，在新的复制链路没有故障时，如果原主节点恢复，是不会回切的。如果当前复制链路发生故障，会再次选择权重高的进行切换

Answer 4

Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysqlinstance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
MySQL 复制的基本过程如下：
1. Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2. Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 BinaryLog 文件的名称以及在 Binary Log 中的位置;
3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”
4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。