MySQL 主从复制与读写分离概念及架构分析

1.MySQL主从复制入门

首先,我们看一个图:

影响MySQL-A数据库的操作,在数据库执行后,都会写入本地的日志系统A中


假设,实时的将变化了的日志系统中的数据库事件操作,在MYSQL-A的3306端口,通过网络发给MYSQL-B。

MYSQL-B收到后,写入本地日志系统B,然后一条条的将数据库事件在数据库中完成。

那么,MYSQL-A的变化,MYSQL-B也会变化,这样就是所谓的MYSQL的复制,即MYSQL replication。

在上面的模型中,MYSQL-A就是主服务器,即master,MYSQL-B就是从服务器,即slave。

日志系统A,其实它是MYSQL的日志类型中的二进制日志,也就是专门用来保存修改数据库表的所有动作,即bin log。【注意MYSQL会在执行语句之后,释放锁之前,写入二进制日志,确保事务安全】

日志系统B,并不是二进制日志,由于它是从MYSQL-A的二进制日志复制过来的,并不是自己的数据库变化产生的,有点接力的感觉,称为中继日志,即relay log。

可以发现,通过上面的机制,可以保证MYSQL-A和MYSQL-B的数据库数据一致,但是时间上肯定有延迟,即MYSQL-B的数据是滞后的。

【即便不考虑什么网络的因素,MYSQL-A的数据库操作是可以并发的执行的,但是MYSQL-B只能从relay log中读一条,执行下。因此MYSQL-A的写操作很频繁,MYSQL-B很可能跟不上。】

2.主从复制的几种方式


同步复制

所谓的同步复制,意思是master的变化,必须等待slave-1,slave-2,...,slave-n完成后才能返回。

这样,显然不可取,也不是MYSQL复制的默认设置。比如,在WEB前端页面上,用户增加了条记录,需要等待很长时间。

异步复制

如同AJAX请求一样。master只需要完成自己的数据库操作即可。至于slaves是否收到二进制日志,是否完成操作,不用关心。MYSQL的默认设置。

半同步复制

master只保证slaves中的一个操作成功,就返回,其他slave不管。

这个功能,是由google为MYSQL引入的。

3.主从复制分析

问题1:master的写操作,slaves被动的进行一样的操作,保持数据一致性,那么slave是否可以主动的进行写操作?

假设slave可以主动的进行写操作,slave又无法通知master,这样就导致了master和slave数据不一致了。因此slave不应该进行写操作,至少是slave上涉及到复制的数据库不可以写。实际上,这里已经揭示了读写分离的概念。

问题2:主从复制中,可以有N个slave,可是这些slave又不能进行写操作,要他们干嘛?

可以实现数据备份。

类似于高可用的功能,一旦master挂了,可以让slave顶上去,同时slave提升为master。

异地容灾,比如master在北京,地震挂了,那么在上海的slave还可以继续。

主要用于实现scale out,分担负载,可以将读的任务分散到slaves上。

【很可能的情况是,一个系统的读操作远远多于写操作,因此写操作发向master,读操作发向slaves进行操作】

问题3:主从复制中有master,slave1,slave2,...等等这么多MYSQL数据库,那比如一个JAVA WEB应用到底应该连接哪个数据库?

当 然,我们在应用程序中可以这样,insert/delete/update这些更新数据库的操作,用connection(for master)进行操作,select用connection(for slaves)进行操作。那我们的应用程序还要完成怎么从slaves选择一个来执行select,例如简单的轮循算法。

这样的话,相当于应用程序完成了SQL语句的路由,而且与MYSQL的主从复制架构非常关联,一旦master挂了,某些slave挂了,那么应用程序就要修改了。能不能让应用程序与MYSQL的主从复制架构没有什么太多关系呢?可以看下面的图:

找一个组件,application program只需要与它打交道,用它来完成MYSQL的代理,实现SQL语句的路由。

mysql proxy并不负责,怎么从众多的slaves挑一个?可以交给另一个组件(比如haproxy)来完成。

这就是所谓的MYSQL READ WRITE SPLITE,MYSQL的读写分离。

问题4:如果mysql proxy , direct , master他们中的某些挂了怎么办?

总统一般都会弄个副总统,以防不测。同样的,可以给这些关键的节点来个备份。

问题5:当master的二进制日志每产生一个事件,都需要发往slave,如果我们有N个slave,那是发N次,还是只发一次?

如果只发一次,发给了slave-1,那slave-2,slave-3,...它们怎么办?

显 然,应该发N次。实际上,在MYSQL master内部,维护N个线程,每一个线程负责将二进制日志文件发往对应的slave。master既要负责写操作,还的维护N个线程,负担会很重。可 以这样,slave-1是master的从,slave-1又是slave-2,slave-3,...的主,同时slave-1不再负责select。 slave-1将master的复制线程的负担,转移到自己的身上。这就是所谓的多级复制的概念。

问题6:当一个select发往mysql proxy,可能这次由slave-2响应,下次由slave-3响应,这样的话,就无法利用查询缓存了。

应该找一个共享式的缓存,比如memcache来解决。将slave-2,slave-3,...这些查询的结果都缓存至mamcache中。

时间: 2024-10-26 22:12:19

MySQL 主从复制与读写分离概念及架构分析的相关文章

mysql主从复制与读写分离

MySQL主从复制与读写分离 MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践 Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过.但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面. 因此,一般来说都是通过 主从复制(Master-Slave)的方式来同步数据,再通过读写分离(MySQL-Proxy)来提升数据库的并发负载能力 这样的方案来进行部

MySQL主从复制、读写分离、高可用集群搭建

MySQL主从复制.读写分离.高可用集群搭建  一.服务介绍   1.1 Keepalived     Keepalived,见名知意,即保持存活,其目的是解决单点故障,当一台服务器宕机或者故障时自动切换到其他的服务器中.Keepalived是基于VRRP协议实现的.VRRP协议是用于实现路由器冗余的协议,VRRP协议将两台或多台路由器设备虚拟成虚拟设备,可以对外提供虚拟路由器IP(一个或多个),即漂移IP(VIP). 1.2 ProxySQL ProxySQL是一个高性能,高可用性的MySQL

Mysql主从复制、读写分离工作原理+配置

Mysql的 Replication 是一个异步的复制过程,从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysqlinstance(我们称之 Slave).在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端. MySQL 复制的基本过程如下: 1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开

MySQL 主从复制与读写分离

Mysql主从复制作用原理 1.在业务复杂的系统中,有这么一个情景,有一句sql语句需要锁表,导致暂时不能使用读的服务,那么就很影响运行中的业务,使用主从复制,让主库负责写,从库负责读,这样,即使主库出现了锁表的情景,通过读从库也可以保证业务的正常运作.2.做数据的热备3.架构的扩展.业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的频率,提高单个机器的I/O性能.mysql主从复制是一个异步的复制过程,主库发送更新事件到从库,从库读取更新记录,并执行更新记

重新学习Mysql数据13:Mysql主从复制,读写分离,分表分库策略与实践

一.MySQL扩展具体的实现方式 随着业务规模的不断扩大,需要选择合适的方案去应对数据规模的增长,以应对逐渐增长的访问压力和数据量. 关于数据库的扩展主要包括:业务拆分.主从复制.读写分离.数据库分库与分表等.这篇文章主要讲述数据库分库与分表 (1)业务拆分 在?大型网站应用之海量数据和高并发解决方案总结一二?一篇文章中也具体讲述了为什么要对业务进行拆分. 业务起步初始,为了加快应用上线和快速迭代,很多应用都采用集中式的架构.随着业务系统的扩大,系统变得越来越复杂,越来越难以维护,开发效率变得越

Mysql 主从复制,读写分离

Mysql 主从复制及读写分离 特别推荐看:amoeba.xml 的配置部分,在百度上看了很多配置都不完整,是我测试时的痛点 实验的目的: 有两部分:第一实现Mysql主从复制,第二实现读写分离. 下面是实验的环境: 192.168.58.11     安装了amoeba 的节点 192.168.58.16      master    系统:rhel 5.4 192.168.58.12      slave     系统: rhel 5.4 192.168.58.11      代理     

搭建 MySQL主从复制与读写分离

搭建 MySQL主从复制与读写分离 案例概述 : 在实际环境中 ,如果对数据库的读和写都在同一个数据库服务中操作 ,无论实在安全性.高可用性, 还是高并发等各个方面都是完全不能满足实际需求的 ,因此 ,一般来说都只通过主从复制的方式来同 步数据 ,在通过读写分离来提升数据库的并发负载能力 ,这样的方案来进行部署与实施 . 环境拓补图 : 本案环境 : 主机 操作系统 IP地 址 主要软件 主服务器 CentOS 7.3 x86_64 192.168.217.130 NTP 从服务器1 CentO

Amoeba搭建高可用Mysql集群(实现Mysql主从复制、读写分离、负载均衡)

Amoeba是什么? Amoeba(变形虫)项目,该开源框架于2008年 开始发布一款 Amoeba for Mysql软件.这个软件致力于MySQL的分布式数据库前端代理层,它主要在应用层访问MySQL的时候充当SQL路由功能,专注于分布式数据库代理层(Database Proxy)开发,它位于与Client.DBServer(s)之间,对客户端透明.具有 负载均衡.高可用性.SQL过滤.读写分离.可路由相关的到目标数据库.可并发请求多台数据库合并结果 . 通过Amoeba你能够完成多数据源的

mysql主从复制以及读写分离

mysql的主从复制以及读写分离 前言:我们前面搭建过LAMP和LNMP,做过了web服务器群集和热备,web服务器坏了我们是不怕了,但是我们要知道,网站的数据有很多是存储在数据库里面的,例如注册的会员,发的文章,购物的订单等信息.当然我们可以给数据库做备份,但是如果每天00:00做一次备份,那么如果在23:59数据丢失了,那么就会丢失一天的数据,有没有一种方法能实现实时备份,就是说有数据产生就立即备份,答案当然是有,也就是今天我们要学习的mysql主从复制.有点类似于前面我们学习过的rsync