MySQL高可用性(DOC可编).docVIP

Mysql replication report 1 基本用途 2 基本原理 3 搭建过程 4 导致master 和slave 不同步的原因 Mysql replication的历程 6 数据库不同步的一些解决方案 Replication的用途： 1 数据分发 ,scale out，sacle up ，垂直划分，水平划分 2 负载均衡 load balance 3 备份，一般不会用作备份，一旦执行delete操作，replication也不会保留 4 高可用 5 可以在不同的主从库上使用不同的存储引擎 6 测试mysql的升级 常见replication的架构 常见的负载均衡架构 当使用的slavae过多时，减轻master压力的级联架构，master2打开log-slave-updates配置 一台masterdown时候的，冗余架构 Replication不同的库到不同的主机 原理 1 三个进程： Mysql的复制（replication）是一个异步的复制，从一个Master复制到另一个Slave。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上show processlist查看，slave上可以直线show slave status进行查看，里面的 Slave_IO_Running: No Slave_SQL_Running: No，是两个进程的状态是否在运行。Mysql4.0是两个进程，后有yahoo的一位工程师提出的3个进程，博客为:/mysql/ 2 三个log文件和两个info文件： 复制进行时，在master上执行的语句会记录到bin.log里面，日志的位置和数字，当有变化 放生时，slave 会通过一个io进程读取master的二进制log，发现有变化时候，会把新的变化副知道他的relay.log,会记录行的位置和数字到一个新的文件叫，继续检查master的二进制log，当slave的sql进程发现在relay.log里有变化时候会执行，同时slave也会通过sql 进程去对比master和slave的变化，如果对比发现不一致，复制进程会停止并把错误信息计入 slave的error.log,如果结果能对的上，一个新的日子的位置和数字会记录到 slave会等另外一个变化到relay log文件。 3 复制的基本过程如下：Relay log，slave通过重放relay log，然后就写进自己的log1)、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端真实执行时候的那些可执行的内容，并在自身执行Replication的两种复制级别： Statement level级别 mysql 3.23后 每一条修改数据的query都会记录到master的binary log 中，slave 复制时候sql线程会解析成合原来的master端执行过的相同的query. 优点是： 不需记录每条变化，减少log，节省io。 缺点是：必须每条语句相关信息，即上下文信息。 Row level级别 5.1以后： Binary log会记录成每一行数据被修改的形式，然后在slave端口对相同的数据进行修改。锁表操作会大量减少。 优点：不需记录执行query语句的上下文信息，只需要记录那条被修改了，修改成什么了。 缺点是：产生的log记录比较大 还有一种不常用的mixed级别。 搭建过程 可以参考mysql官方文档: 步骤： 1 Creating a User for Replication 2 Setting the Replication Master Configuration 3 Setting t