主服务器(master)简称M,从服务器(slave)简称S
  一、原理:  M监听S的复制请求,S创建一个I/O线程以连接M并让它发送记录在其二进制日志中的语句,M接受到请求,创建一个Binlog Dump线程将二进制日志中的内容发送到S,S的I/O线程读取M的Binlog Dump线程发送的内容并将该数据拷贝到S的数据目录中的本地文件中,即中继日志。第3个线程是SQL线程,是S创建用于读取中继日志并执行日志中包含的更新。
    当M有数据更新,会去自动通知S,通过在S上可以看到

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 10
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Waiting for master to send event   #等待M发送更新的数据
   Info: NULL


二、复制配置
首先要保证两边的数据一致。

在M上添加复制的用户
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.1.251' IDENTIFIED BY '123456';
1
)配置master服务器/etc/my.cnf文件

 

log-bin=mysql-bin
启动二进制日志系统
#binlog-do-db=test
我这里加个#号是因为在master最好不要加上这个参数,如果在slave做过滤数据库的话,会导致有些数据被过滤掉
server-id = 1
本机数据库ID 标示为主,该部分还应有一个server-id=Master_id选项,其中master_id必须为1到232–1之间的一个正整数值
log-bin=/var/log/mysql/updatelog
#设定生成log文件名,这里的路径没有mysql目录要手动创建并给于它mysql用户的权限。
binlog-ignore-db=mysql
避免同步mysql用户配置,以免不必要的麻烦

2)配置slave服务器/etc/my.cnf文件

将以下配置启用:

server-id = 2
从服务器ID号,不要和主ID相同 
如果设置多个从服务器,每个从服务器必须有一个唯一的server-id值,必须与主服务器的以及其它从服务器的不相同。可以认为server-id值类似于IP地址:这些ID值能唯一识别复制服务器群集中的每个服务器实例。
master-host = 192.168.1.1
指定主服务器IP地址
master-user = replication
制定在主服务器上可以进行同步的用户名
master-password = 123456
密码
master-port = 3306
同步所用的端口
master-connect-retry=60
断点重新连接时间
replicate-ignore-db=mysql
屏蔽对mysql库的同步,以免有麻烦
replicate-do-db=test
同步数据库名称
3)在master上查看二进制日志的pos值
mysql> show master status;          #显示(不同主机结果不同)


+------------------+----------+-------------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+-------------------+------------------+

| updatelog.000028 | 313361 |db1 | mysql |

+------------------+----------+-------------------+------------------+


4)在slave上用change master to master_log_file='
updatelog.000028',master_log_pos=313361;
然后start slave;
三、复制实现级别 Mysql的复制可以是基于一条语句(Statement level),也可以是基于一条记录(Row level),可以在Mysql的配置参数中设定这个复制级别,不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。 Row Level:日志中会记录成每一行数据被修改的形式,然后在slave端再对相同的数据进行修改。 优点:在row level模式下,bin-log中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程,或function,以及 trigger的调用和触发无法被正确复制的问题。 缺点:row level下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条update语 句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,执行之后,日志中记录的不是这条update语句所对应额事件(mysql以事件的形式来记录bin-log日志),而是这条语句所更新的每一条 记录的变化情况,这样就记录成很多条记录被更新的很多个事件。自然,bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候,产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动,实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。 Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。 优点:statement level下的优点首先就是解决了row level下的缺点,不需要记录每一行数据的变化,减少bin-log日志量,节约IO,提高性能。因为他只需要记录在Master上所执行的语句的细节,以及执行语句时候的上下文的信息。 缺点:由于他是记录的执行语句,所以,为了让这些语句在slave端也能正确执行,那么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信 息,以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是,由于Mysql现在发展比较快,很多的新功能不 断的加入,使mysql得复制遇到了不小的挑战,自然复制的时候涉及到越复杂的内容,bug也就越容易出现。在statement level下,目前已经发现的就有不少情况会造成mysql的复制出现问题,主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现,比 如:sleep()函数在有些版本中就不能真确复制,在存储过程中使用了last_insert_id()函数,可能会使slave和master上得到 不一致的id等等。由于row level是基于每一行来记录的变化,所以不会出现类似的问题。 从官方文档中看到,之前的Mysql一直都只有基于statement的复制模式,直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始,Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现,给Mysql的复制又带来 了更大的新挑战。另外,看到官方文档说,从5.1.8版本开始,Mysql提供了除Statement Level和Row Level之外的第三种复制模式:Mixed,实际上就是前两种模式的结合。在Mixed模式下,Mysql会根据执行的每一条具体的sql语句来区分对 待记录的日志形式,也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样,仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录,如果sql语句确实就是update或者delete等修改数据的语句, 那么还是会记录所有行的变更。 mysql复制FAQ 每次当复制中断,修复复制出现的错误之后,在S上用show slave status 查看二进制日志的pos值,
然后用change master to来指定(这里必须首先要停止复制)。然后启动复制(start slave)


自己在维护中mysql复制出现了一些错误,我都把错误的解决方法记录在此链接
http://xinying.blog.51cto.com/441770/142877

四、mysql复制监控
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.1
Master_User:
replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File:
updatelog.000028
Read_Master_Log_Pos: 132430
Relay_Log_File: DBserver1-relay-bin.004421
Relay_Log_Pos: 132575
Relay_Master_Log_File:
updatelog.000028 #执行到哪个二进制文件啦
Slave_IO_Running: Yes #I/O线程是否运行正常,YES代表正常
Slave_SQL_Running: Yes #SQL线程是否运行正常,YES代表正常
Replicate_Do_DB: test
Replicate_Ignore_DB: mysql
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 132430 #执行到二进制文件的POS值,对应于
Relay_Master_Log_File
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0 #落后master多少
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
#如果I/O线程出错,这里会出现错误信息
Last_SQL_Errno: 0
Last_SQL_Error:
#如果SQL线程出错,这里会出现错误信息
1 row in set (0.00 sec)


自己可以写个脚本判断这些参数,我这里贴出PHP写的脚本
<php
include ("sendsms.php")    #这是调用短信平台的头文件
$link=mysql_connect("localhost","root","123456");
  $db = mysql_select_db("mysql",$link);
  $result = mysql_query("show slave status",$link);
        $row = mysql_fetch_array($result);
        
  if (trim($row["Slave_IO_Running"]) == "No" || trim($row["Slave_SQL_Running"]) == "No")
  {
        //判断I/O线程或者SQL线程是否运行正常,如果不正常就发送短信
             $mobile="13888888888";
        $msg = "Master_Host:".$row["Master_Host"].",Last_IO_Errno:".$row["Last_IO_Errno"].",Last_IO_Error:".$row["Last_IO_Error"].",Last_SQL_Errno:".$row["Last_SQL_Errno"].",Last_SQL_Error:".$row["Last_SQL_Error"];
        sendMsg($mobile,$msg);
  }
  
  //echo $msg;

?>