grant replication slave on . to '用户名'@'主机' identified by '密码';
如果利用的是MySQL 4.0.2之前的版本，则用file权限来代替replication slave
编辑主理事器的配置文件：/etc/my.cnf
binlog_do_db是指定binlog日志记录那些库的二进制日志。replicate_do_db则在slave库中指定同步那些库的binlog日志。
在主从互备环境中，有没有必要每个做事器都同时配置binlog_do_db和replicate_do_db?情由是什么？
binlog-do-db：指定mysql的binlog日志记录哪个db
Replicate_Do_DB：参数是在slave上配置，指定slave要复制哪个库
在master上设置binlog_do_弊端：
1、过滤操作带来的负载都在master上
2、无法做基于韶光点的复制（利用binlog）。
server-id=1
log-bin
binlog-do-db=须要复制的数据库名，如果复制多个数据库，重复设置这个选项即可
binlog-ignore-db=不须要复制的数据库苦命，如果复制多个数据库，重复设置这个选项即可
把稳：如果你想做一个繁芜点的构造：比如说，A->B->C，个中B是A的从做事器，同时B又是C的主理事器，那么B做事器除了须要打开log-bin之外，还须要打开log-slave-updates选项，你可以再B上利用“show variables like 'log%';”来确认是否已经生效。
编辑从做事器的配置文件：/etc/my.cnf
server-id=2
master-host=主机
master-user=用户名
master-password=密码
master-port=端口
replicate-do-db=须要复制的数据库名，如果复制多个数据库，重复设置这个选项即可
replicate-ignore-db=须要复制的数据库名，如果复制多个数据库，重复设置这个选项即可
配置主从做事器的my.cnf时，把稳各自的server-id一定要彼此独立，不能重复，否则，会涌现如下缺点：
Slave: received end packet FROM server, apparent master shutdown
另一个须要把稳的是最好在从做事器的my.cnf里设置read_only选项，防止发生意外（连接用户不能有SUPER权限，否则无效）。
记得先手动同步一下主从做事器，数据量小的话可以用mysqldump，它有一个master-data参数很有用，通过利用此参数，导出的SQL文件里会自动包含CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=...;，这样创建从做事器就更方便了。
如果数据量大的话不太适宜利用mysqldump（慢），如果是myisam表的话，加上--lock-all-tables参数，如果是innodb表的话，加上--single-transaction参数。
而该当采取拷贝文件的办法，请按如下操作步骤：
先在主理事器上锁定所有的表，以免在复制过程中数据发生变革：
mysql> flush tables with read lock;
然后在主理事器上查询当前二进制文件的文件名及偏移位置：
mysql > show master status;
然后停滞主理事器上的MySQL做事：
shell> mysqladmin -u root shutdown
把稳：如果仅是MyISAM的话，可以一直止MySQL做事，但要在复制数据文件的过程中保持只读锁，如果是InnoDB的话，必须停滞MySQL做事。
再拷贝数据文件：
shell> tar -cvf /tmp/mysql-snapshot.tar .
拷贝完别忘了启动主理事上的MySQL做事了。
然后把数据文件运用到从做事器上，再次启动slave的时候利用，记得启动时加上skip-slave-start选项，使之不会急速去连接master，再在从做事器上设置干系的二进制日志信息：
mysql> CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
启动从做事器上的复制线程：
mysql> start slave;
验证主从设置是否已经成功，可以输入如下命令：
mysql> show slave status\G
会得到类似下面的列表：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
如果这两个选项不全是Yes，那就解释你前面某个步骤配置错了。
该当担保从做事器上任何数据的修正都是通过从主理事器上复制操作获取的，换句话说，从做事器该当是只读的，如果不能担保这一点，则可能造成主从数据不一致。可以在从做事器的my.cnf里加入read-only参数来实现这一点，唯一须要把稳的一点事read-only仅对没有super权限的用户有效。以是最好核对一下连接从做事器的用户，确保其没有super权限。
从空想角度看，主从数据库该当无端障的运转下去，可以有时候还是会涌现一些莫名其妙的问题，比如说即便从未在从做事器上手动更新过数据，但还是可能碰着“Error: 1062 Duplicate entry”缺点，详细缘故原由不详，可能是MySQL本身的问题。碰着这类问题的时候，从做事器会停滞复制操作，我们只好手动办理问题，详细的操作步骤如下：
mysql> set global sql_slave_skip_counter = 1;
mysql> start slave;
同样的操作可能须要进行多次，也可以设置自动处理此类操作，在从做事器的my.cnf里设置：
slave-skip-errors=1062
末了再唠叨一下日志的问题：韶光长了，数据库做事器上的二进制文件会越来越多，清理是必要的，你可以设置自动清理，干系参数是expire_logs_days，也可以利用手动删除的办法，但这里说的手动不是指rm，而是指PURGE BINARY LOGS，删除任何日志前，最好在所有的从做事器上通过show slave status命令确认一下干系日志是否已经无用。
更详细的先容参考官方文档：How to Set Up Replication，不喜好英文的话可以看老叶同道的中文翻译。
补充：[ERROR] Error in Log_event::read_log_event(): 'Event too big'
在利用主从复制的时候，涌现的问题多数是和日志（主理事器的二进制日志，从做事器的延迟日志）干系的。比如说加入你碰着了上面的缺点，你可以根据缺点日志的信息在主从数据库做事器上分别实行：
mysqlbinlog 日志文件 > /dev/null
查看缺点，如果没有缺点，则不会有任何输出，反之会输出错误信息，如果确定了缺点是涌如今主理事器二进制日志上，可以跳过适当的位置，再在从做事器上重新设定LOG_POS，如果确定了缺点是涌如今从做事器延迟日志上，则可以删除从做事器的延迟日志（利用CHANGE TO MASTER的时候，除非设定了延迟日志信息，否则会自动删除延迟日志），并在从做事器上重新设定LOG_POS。期间也可以考虑手动实行不能自动实行的SQL日志。
补充：配置的时候如果版本许可最好打开sync_binlog选项。
补充：有时候，从做事器延迟日志可能已经破坏，这时须要实行CHANGE MASTER TO设置新的日志文件信息，但是在从做事器上SHOW SLAVE STATUS会显示很多日志信息，他们的含义有所不同：
Master_Log_File:Read_Master_Log_Pos 是IO干系的日志信息
Relay_Master_Log_File:Exec_Master_Log_Pos 是SQL干系的日志信息
从做事器须要设置的是SQL干系的日志信息：
slave stop;
change master to master_log_file=’(binlog name in relay_master_log_file)’, master_log_pos=(exec_master_log_pos number);
slave start;
1) When you are using the master as a consistent snapshot, use SHOW MASTER STATUS to determine the position.
2) When you are using a slave as a consistent snapshot, use SHOW SLAVE STATUS and Exec_Master_Log_Pos.
