cn体育门户网站源码,网站平台建设需要多少钱,企业系统规划,贵阳市网站优化1、复制进程Mysql的复制(replication)是一个异步的复制#xff0c;从一个Mysqlinstace(称之为Master)复制到另一个Mysqlinstance(称之Slave)。实现整个复制操作主要由三个进程完成的#xff0c;其中两个进程在Slave(Sql进程和IO进程)#xff0c;另外一个进程在Master(IO进程…1、复制进程Mysql的复制(replication)是一个异步的复制从一个Mysqlinstace(称之为Master)复制到另一个Mysqlinstance(称之Slave)。实现整个复制操作主要由三个进程完成的其中两个进程在Slave(Sql进程和IO进程)另外一个进程在Master(IO进程)上。要实施复制首先必须打开Master端的binarylog(bin-log)功能否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。复制的基本过程如下1)、Slave上面的IO进程连接上Master并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容2)、Master接收到来自Slave的IO进程的请求后通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息返回给Slave的IO进程。返回信息中除了日志所包含的信息之外还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置3)、Slave的IO进程接收到信息后将接收到的日志内容依次添加到Slave端的relay-log文件的最末端并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容请发给我”4)、Slave的Sql进程检测到relay-log中新增加了内容后会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容并在自身执行。实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题主要如下首先一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程性能受到了一定的限制异步复制的延迟也会比较长。另外Slave端从Master端获取bin-log过来之后需要接着解析日志内容然后在自身执行。在这个过程中Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave端的压力比较大的时候这个过程的时间可能会比较长。所以后面版本的Mysql为了解决这个风险并提高复制的性能将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“JeremyZawodny”。这样既解决了性能问题又缩短了异步的延时时间同时也减少了可能存在的数据丢失量。当然即使是换成了现在这样两个线程处理以后同样也还是存在slave数据延时以及数据丢失的可能性的毕竟这个复制是异步的。只要数据的更改不是在一个事物中这些问题都是会存在的。如果要完全避免这些问题就只能用2、复制实现级别Mysql的复制可以是基于一条语句(Statement level)也可以是基于一条记录(Rowlevel)可以在Mysql的配置参数中设定这个复制级别不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。RowLevel日志中会记录成每一行数据被修改的形式然后在slave端再对相同的数据进行修改。优点在rowlevel模式下bin-log中可以不记录执行的sql语句的上下文相关的信息仅仅只需要记录那一条记录被修改了修改成什么样了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节非常容易理解。而且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题。缺点rowlevel下所有的执行的语句当记录到日志中的时候都将以每行记录的修改来记录这样可能会产生大量的日志内容比如有这样一条update语句update product set owner_member_id ‘b’ where owner_member_id ‘a’执行之后日志中记录的不是这条update语句所对应额事件(Statement Level:每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。优点statement level下的优点首先就是解决了rowlevel下的缺点不需要记录每一行数据的变化减少bin-log日志量节约IO提高性能。因为他只需要记录在Master上所执行的语句的细节以及执行语句时候的上下文的信息。缺点由于他是记录的执行语句所以为了让这些语句在slave端也能正确执行那么他还必须记录每条语句在执行的时候的一些相关信息也就是上下文信息以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是由于Mysql现在发展比较快很多的新功能不断的加入使从官方文档中看到之前的Mysql一直都只有基于statement的复制模式直到5.1.5版本的Mysql才开始支持rowlevel的复制。从5.0开始Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现给Mysql的复制又带来了更大的新挑战。另外看到官方文档说从5.1.8版本开始Mysql提供了除Statement Level和RowLevel之外的第三种复制模式Mixed实际上就是前两种模式的结合。在Mixed模式下Mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式也就是在Statement和Row之间选择一种。新版本中的Statmentlevel还是和以前一样仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化并不是所有的修改都会以rowlevel来记录像遇到表结构变更的时候就会以statement模式来记录如果sql语句确实就是update或者delete等修改数据的语句那么还是会记录所有行的变更。3、复制常用架构Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大(尤其是slave端压力)的话异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后更是减小了slave端的延时。而带来的效益是对于数据实时性要求不是特别的敏感度的应用只需要通过廉价的pcserver来扩展slave的数量将读压力分散到多台slave的机器上面即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题甚至有些大型网站也在使用类似方案解决数据库瓶颈。一个Master带多个slave的架构实施非常简单多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个slave连上了master端只要有slave进程通过了连接认证向他请求binlog信息他就会按照连接上来的io进程的要求读取自己的binlog信息返回给slave的IO进程。对于slave的配置细节在Mysql的官方文档上面已经说的很清楚了甚至介绍了多种实现slave的配置方法。Mysql不支持一个Slaveinstance从属于多个Master的架构。就是说一个slaveinstance只能接受一个master的同步源听说有patch可以改进这样的功能但没有实践过。MysqlAB之所以不实现这样的功能主要是考虑到冲突解决的问题。Mysql也可以搭建成dual master模式也就是说两个Mysqlinstance互为对方的Master也同时为对方的Slave。不过一般这种架构也是只有一端提供服务避免冲突问题。因为即使在两边执行的修改有先后顺序由于复制的异步实现机制同样会导致即使在晚做的修改也可能会被早做的修改所覆盖就像如下情形时间点 MysqlA Mysql B1 更新x表y记录为102 更新x表y记录为203 获取到A日志并应用更新x表的y记录为10(不符合期望)4 获取B日志更新x表y记录为20(符合期望)这样不仅在B库上面的数据不是用户所期望的结果A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端保证不会交叉写入才能够避免上面的问题。
