MySQ里的主从复制

一、如何让web服务器从数据库集群里读取数据更快些？解决大并发的问题

如何实现流量分流，进行读写分离。
集群：cluster：多台MYSQL服务器
集群：很多台服务器做一样的事情
那么如何保证数据库里的内容是一样的，如何进行分工呢？

二、主从复制的作用

实现负载均衡，起到一个备份作用。
一台主数据库机器进行写操作，其他的多台从数据库机器进行读操作（使用二进制日志进行复制）

主从复制：主机器执行insert、update、delete语句的时候，从机器也会进行一样的操作。因为从服务器需要从主机器里拷贝二进制日志，然后根据二进制日志的内容去执行SQL，从而达到主从服务器里的数据一模一样。首先会在master机器上面就是开启一个二进制日志。slave机器上会有一个io线程去同步这些二进制日志。

slave机器上有一个io线程 manager–master管理节点
worker 工作节点 node：节点

三、MYSQL上的主从复制原理逻辑图

MYSQL的主从复制原理逻辑流程：
1、首先在master上面开启二进制日志
2、master上数据发生变化，进行DML操作的时候，会产生二进制日志。（DML操作：insert插入 update 更新 delete 删除数据）
3、master上的dump线程会通知slave上的io线程来拿二进制日志，io线程拿到二级制日志后写入slave上的中继日志，然后sql线程会去读新产生的中继日志，重演二进制里的操作，从而达到slave和master上的数据一模一样，实现数据的一致性。

四、到底是主服务器主动通知从服务器来取二进制日志，还是从服务器每隔一段时间来拿二进制日志？

主服务器主动通知从服务器过来拿二进制日志。

五、主服务器如何知道从服务器上已经有哪些数据了，需要从哪里开始给数据给从服务器？

（1）在slave服务器上执行start slave命令开始主从复制开关，开始进行主从复制
（2）此时，slave服务器的IO线程会通过在master上已经授权的复制用户权限请求链接到master服务器，并请求从执行binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。
（3）master服务器接收到来自slave服务器的io线程的请求后，其上负责复制的IO线程会根据slave服务器的io线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给slave端的IO线程。返回的信息中除了binlog日志内容外，还有在master服务器记录的io线程。返回的信息中有binlog中的下一个指定更新位置。
（4）当slave服务器的io线程获取到master服务器上dump线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到slave端自身的relaylog（即中继日志）文件（mysql-relay-bin.xxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容。
（5）slave服务器端的SQL线程会实时检测本地relay
log中IO线程新增的日志内容，然后及时把relaylog文件中的内容解析成sql语句，并在自身slave服务器上按解析sql语句的位置顺序执行应用这样sql语句，并在relay-log,info中记录当前应用中继日志的文件名和位置点。

1、从服务器如何知道谁是它的主服务器

master-info文件的作用

会记录mater的ip，连接过去复制二进制日志的账号和密码，会记录日志结束的pos位置号，日志文件的名字。

relay-log.info文件的作用

relay-log.info 存储从库 SQL 线程（负责重放中继日志的线程）的当前执行位置（当前Relay Log 文件名、已执行到的日志位置、）确保从库重启或故障恢复时，SQL 线程能从上次中断的位置继续应用 Relay Log，避免重复执行或遗漏事务。

六、主从复制过程中如何保证数据的真实性

1、基于日志的复制和事务一致性

主从复制保证数据真实性的机制：在基于日志的复制（如mysql的binlog日志复制中），主服务器将数据修改操作记录为事务性的事件序列存存储在二进制日志（binlog）中。这些事件严格按照事务提交发顺序记录，从服务器通过读取binlog并按照相同顺序执行事物，来保证数据的一致性。

例如：一个包含多个相关数据修改操作的事务（如银行转账涉及的扣款和收款操作）在主服务器上作为一个原子操作记录在binlog中。从服务器会完整地执行主管事务，确保数据状态的转移和主服务器一致。

2、校验与数据校验机制

一些数据库系统在数据传输过程中（如从主服务器发送数据到从服务器）会使用校验和机制。例如，对每一个数据块或者日志事件计算校验和，从服务器接收数据后重新计算校验和并与发送过来的校验和进行比较。如果不一致。就会触发数据重传或错误提示，从而保证数据的完整性。
部分数据库还支持在从服务器应用数据后进行数据验证，通过比较主从服务器上关键数据的状态（如某些重要表的行数、关键列的总和等）来验证数据是否一致。

七、 如果主服务器宕机了 从上面就一定能保证数据的一致性不丢失吗？能保证数据的可靠性吗？

1、从服务器不一定能保证数据完全一致不丢失

如果主服务器突然宕机，可能会有正在执行但尚未完全记录到binlog中发事务，这些未完全记录的事务就无法传递给从服务器，从而导致主从数据不一致。
例如：主服务器在执行一个复杂的存储过程，在事务提交过程中宕机，部分操作已经在内存中执行但还没来得及写入binlog，从服务器就无法获取这部分操作，进而数据不一致。

2、数据丢失的风险

即使从服务器已经获取了大部分主服务器的数据修改操作。但是如果主服务器上的最新数据修改还没来得及发送给从服务器，当主服务器宕机且数据无法恢复时，这部分数据就会丢失。
例如：主服务器收到一个新的订单记录并更新数据库后，还没来得及将这个更新操作发送给从服务器就宕机了，从服务器就会丢失这个新订单记录。

八、如果不能保证可靠性的话 出现这种问题的话 我们应该如何保证的呢？应该如何操作？

半同步复制（以mysql为例）
原理：半同步复制是一种介于异步复制和完全同步复制之间的复制方式。在半同步复制模式下，主服务器在执行一个事务的提交操作时，会等待至少一个从服务器接收到并写入中继日志（relay log）后，才返回客户端事务提交成功的消息。这样可以在一定程度上保证从服务器已经接收到了关键的事务信息，减少数据丢失的风险。