中山商城网站建设,网站设计专业有哪些课程,ui设计师职业规划,wordpress管理员用户名更改一、常见的高可用MySQL解决方案 1.1、主从复制解决方案 主从复制解决方案实现原理主从复制的整体逻辑是#xff1a; 《1》客户端需要写入数据#xff0c;一般是先写到主库【即#xff1a;主库启动就开启binlog功能#xff08;实现将写入到主库的每一个SQL操作都会做记录 《1》客户端需要写入数据一般是先写到主库【即主库启动就开启binlog功能实现将写入到主库的每一个SQL操作都会做记录】 《2》与此同时主库在启动的时候就启动了【load dump线程】该线程的主要作用是监测binlog的变化一旦监测到binlog有变化就将变化的内容发送到所有从库 《3》从库的【IO线程】是用来接收处理主库发送来的binlog日志该线程接收到binlog日志后会在本地生成【中继日志(relay log)并不断地追加写入】中继日志写入到从库磁盘后会返回一个响应给到主库主库接收到响应就认为从库接收到的内容写入成功了 《4》从库的【SQL线程】是监测中继日志(Relay Log)的当监测到中继日志变动后该线程会立刻解析中继日志的内容并且将中继日志上的SQL内容都全部执行一遍(又叫做回放)这样就实现了从库和主库的数据同步。 MySQL Replication是一个从Master复制到一个或多个Slave的、异步的过程在Master与Slave之间实现整个复制过程主要由三个线程来完成其中一个IO线程在Master端另两个线程Sql线程和IO线程在Slave端。 要实现Mysql Replication首先要在Master服务器上打开MySQL的Binary Log产生二进制日志文件功能因为整个复制过程实际上就是Slave从Master端获取该日志然后在自身上将二进制文件解析为SQL语句并完全顺序的执行SQL语句所记录的各种操作。更详细的过程如下 1首先Slave上的IO线程连接上Master然后请求从指定日志文件的指定位置或者从最开始的日志位置之后开始读取日志内容。2Master在接收到来自Slave的IO线程请求后通过自身的IO线程根据请求信息读取指定日志位置之后的信息并返回给Slave端的IO线程。返回信息中除了日志所包含的信息之外还包括此次返回的信息在Master端对应的Binary Log文件的名称以及在Binary Log中的位置。3Slave的IO线程接收到信息后将获取到的日志内容依次写入Slave端的Relay Log文件类似于mysql-relay-bin.xxxxxx的最后并且将读取到的Master端的Binary Log的文件名和位置记录到一个名为master-info文件中以便在下一次读取的时候能够迅速定位从哪个位置开始往后读取日志信息。4Slave的SQL线程在检测到Relay Log文件中新增加了内容后会马上解析该Relay Log文件中的内容将日志内容解析为SQL语句然后在自身执行这些SQL由于是在Master端和Slave端执行了同样的SQL操作所以两端的数据是完全一样的。至此整个复制过程结束。主从复制方案的数据同步非常依赖网络若主从之间的网络抖动不稳定会出现主从数据同步不及时的情况因此主从复制服务器都在同一网段内是比较稳定的。 1.2、双主复制解决方案
双主复制解决方案 《1》首先通过mysql官方提供的可以配置主从复制Master-Slave Replication架构mysql本身提供了基于binlog的增量数据同步方案。 《2》然后在mysql各主机上配置一个Keepalive脚本监测当前主机Keepalived使用虚拟路由冗余协议VRRP来管理虚拟IP地址并确保只有一个服务器在处理流量。同时定期检查服务器的健康状态如果服务器出现故障或不可用会自动进行切换。这个过程对应用是透明的。 【双主复制适用于中小型企业】。 双主复制解决方案的优势双主复制解决方案的劣势配置部署比较简单有效只有两个节点不存在多主机选主的问题故障自动切换也能提供不错的可用性保障。Keepalived单点故障但如果Keepalived本身出现故障或配置不当可能会导致无法及时切换或切换失败。数据一致性较差在主从复制过程中由于网络延迟、复制延迟或复制错误等原因可能会导致主从数据库之间的数据不一致。如果应用程序在故障切换后继续写入数据到旧的主服务器在Keepalived切换后可能仍被视为活动节点则会导致数据丢失或冲突。 比如主键冲突更新丢失等。 1.3、MHA高可用解决方案
MHA高可用解决方案 MHAMaster High Availability目前在MySQL高可用方面是一个相对成熟的解决方案它是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中MHA能做到在0~30秒之内自动完成数据库的故障切换操作并且在进行故障切换的过程中MHA能在最大程度上保证数据的一致性以达到真正意义上的高可用。 注意MHA方案只能在MySQL8.0及其更低的版本使用【MHA的底层还是主从复制采用半同步复制】而在MySQL8.0之后的更高版本就不支持了因为高版本的主从复制、插件等、配置、命令等内容都发生了很大的变化因此就无法使用了。 MHA有如下五点优势 《1》故障切换快 《2》master故障不会导致数据不一致 《3》无需修改当前的MySQL设置 《4》无性能下降 《5》适用于任何存储引擎。 1.4、MySQL InnoDB Cluster高可用解决方案
MySQL InnoDB Cluster高可用解决方案 MySQL InnoDB Cluster是MySQL官方提供的一种原生高可用性和高可扩展性解决方案。它通过使用Group Replication来实现数据的自动复制和高可用性并结合MySQL Shell及MySQL Router提供了更全面的高可用解决方案。 MySQL InnoDB Cluster高可用解决方案优势MySQL InnoDB Cluster高可用解决方案劣势 高可用性 通过MySQL Router自动故障转移和内置的管理功能确保数据库的高可用性。 性能稳定性一般 一方面多了MySQL Router转发节点。一方面MySQL Servers集群对网络的稳定性要求较高因为Paxos 协议节点之间需要进行频繁的通信和数据同步。 数据一致性 基于Group Replication 组复制架构使用 Paxos 协议确保了数据在各个服务器实例之间的强一致性。 易于管理 使用MySQL Shell和AdminAPI可以简化集群的安装、配置和管理。 可扩展性 可以轻松地添加或删除服务器实例以适应不同的业务需求。
二、MySQL主从复制的三种类型 2.1、异步复制
异步复制 在mysql异步复制的情况下Master Server将自己的binlog通过复制线程传输出去以后Mysql Master Sever就自动返回数据给客户端而不管slave上是否接受到了这个二进制日志。 那么当master宕机后如果master不能恢复此时只能用slave代替master但slave处于同步落后的状态就会导致数据丢失。优点复制的性能最好缺点master挂掉后slave可能会丢失事务数据不完整。 2.2、全同步复制
全同步复制 在全同步复制中master将自己的binlog写入到bin-log文件并且sync然后向存储引擎提交事务然后一直等待ACK同时要求所有slave接收到binlog写入relay-log后并完成日志回放同时返回ACK确认信息master在接收到所有从库ACK确认信息后才将结果返回给客户端。优点数据不会丢失缺点会阻塞master session性能太差非常依赖网络 2.3、半同步复制 半同步复制又分为两种分别是【传统半同步复制】和【无损半同步复制】是介于异步复制与全同步复制之间。 2.3.1、传统半同步复制
传统半同步复制 在传统半同步复制的架构下master将自己的binlog写入到bin-log文件并且sync且向存储引擎提交事务然后一直等待ACK。当至少一个slave接收到binlog后写入relay-log并返回ACK确认信息。master在接收到从库任意一个ACK确认信息后就将结果返回给客户端。优点会有数据丢失风险但很低。缺点会阻塞master session性能稍差非常依赖网络。由于master是在三段提交的最后commit阶段完成后才等待所以master的其他session是可以看到这个提交事务的所以这时候master上的数据和slave不一致master crash后slave有数据丢失。 2.3.2、无损半同步复制
无损半同步复制 master将自己的binlog写入到binlog文件并且sync之后会进入等待ACK当至少一个slave接收到binlog之后写入relay-log并返回ACK确认信息。master接收到从库ACK确认信息之后向存储引擎提交事务最终返回给客户端。优点数据零丢失性能好缺点会阻塞master session非常依赖网络重点由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的所以这时候master上的数据和slave一致master crash后slave没有丢失数据。
#要开启【无损半同步复制】需要设置如下几个参数
plugin_load rpl_semi_sync_mastersemisync_master.so;rpl_semi_sync_slavesemisync_slave.so
loose_rpl_semi_sync_master_enabled 1
loose_rpl_semi_sync_slave_enabled 1
loose_rpl_semi_sync_master_timeout 5000
三、补充资料 3.1、什么是高可用 高可用需要解决的主要有两个问题【如何实现数据共享或同步数据】【如何处理故障转移(failover)】。 数据共享一般的解决方案是通过SANStorage Area Network来实现而数据同步可以通过rsync软件或DRBD技术来实现故障转移(failover)的意思就是当服务器死机或出现错误时可以自动切换到其他备用的服务器不影响服务器上业务系统的运行。 3.2、MySQL Replication简介、类型和架构
MySQL Replication简介、类型和架构 MySQL Replication是MySQL自身提供的一个主从复制功能其实也就是一台MySQL服务器称为Slave从另一台MySQL服务器称为Master上复制日志然后再解析日志并应用到自身的过程。 《1》MySQL Replication是单向、异步复制基本复制过程为Master服务器首先将更新写入二进制日志文件并维护文件的一个索引以跟踪日志的循环。这些日志文件可以发送到Slave服务器进行更新。当一个Slave服务器连接Master服务器时它从Master服务器日志中读取上一次成功更新的位置。然后Slave服务器开始接收从上一次完成更新后发生的所有更新所有更新完成将等待主服务器通知新的更新。 《2》MySQL Replication支持链式复制也就是说Slave服务器下还可以再链接Slave服务器同时Slave服务器也可以充当Master服务器角色。这里需要注意的是在MySQL主从复制中所有表的更新必须在Master服务器上进行Slave服务器仅能提供查询操作。 MySQL Replication支持多种类型的复制方式常见的有【基于语句的复制】【基于行的复制】【混合类型的复制】基于语句的复制MySQL默认采用基于语句的复制效率很高。基本方式是在Master服务器上执行的SQL语句在Slave服务器上再次执行同样的语句。而一旦发现没法精确复制时会自动选择基于行的复制。基于行的复制基本方式为把Master服务器上改变的内容复制过去而不是把SQL语句在从服务器上执行一遍 从mysql5.0开始支持基于行的复制。混合类型的复制其实就是上面两种类型的组合默认采用基于语句的复制如果发现基于语句的复制无法精确的完成就会采用基于行的复制。MySQL Replication常用架构 一主一从一个Master服务器和一个Slave服务器这是最常见的架构。一主多从一个Master服务器和两个或两个以上Slave服务器。经常用在写操作不频繁、查询量比较大的业务环境中 主主互备 又称双主互备两个MySQL Server互相将对方作为自己的Master自己又同时作为对方的Slave来进行复制。主要用于对MySQL写操作要求比较高的环境中避免了MySQL单点故障。 双主多从 其实就是双主互备然后再加上多个Slave服务器。主要用于对MySQL写操作要求比较高同时查询量比较大的环境中。 其实可以根据具体的情况灵活地将Master/Slave结构进行变化组合但万变不离其宗在进行Mysql Replication各种部署之前有一些必须遵守的规则 《1》同一时刻只能有一个Master服务器进行写操作。 《2》一个Master服务器可以有多个Slave服务器。 《3》无论是Master服务器还是Slave服务器都要确保各自的Server ID唯一不然双主互备就会出问题。 《4》一个Slave服务器可以将其从Master服务器获得的更新信息传递给其他的Slave服务器。 3.3、MySQL的主从复制高可用 主从复制是MySQL自身提供的一种高可用解决方案数据同步方法采用的是MySQL replication技术。【MySQL replication】就是一个日志的复制过程在复制过程中一个服务器充当主服务器而一个或多个其他服务器充当从服务器简单说就是从服务器到主服务器拉取二进制日志文件然后再将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作通过这种方式保证数据的一致性。 【MySQL replication】技术仅仅提供了日志的同步执行功能而从服务器只能提供读操作并且当主服务器故障时必须通过手动来处理故障转移(failover)通常的做法是将一台从服务器更改为主服务器。这种解决方案在一定程度上实现了MySQL的高可用性可以实现90.000%的SLA。 为了达到更高的可用性在实际的应用环境中一般都是采用MySQL replication技术配合高可用集群软件如keepalived、Heartbeat来实现自动故障转移(failover)这种方式可以实现95.000%的SLA。
