MySQL的主从同步是一个很成熟的架构，优点为：
①在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力；
②在从主服务器进行备份，避免备份期间影响主服务器服务；
③当主服务器出现问题时，可以切换到从服务器。
所以我在项目部署和实施中经常会采用这种方案.
+ 数据库目录及其它
my.cnf配置文件 /etc/my.cnf
mysql数据库位置 datadir=/var/lib/mysql
主数据库：192.168.2.119
从数据库：192.168.2.220
操作系统：RHEL5.x 32位
服务器类型: 虚拟机
+ mysql5.0.77 安装:
① 配置好linux的yum服务后，直接yum -y install mysql即可
附：安装phpmysql一条命令安装：yum -y install httpd php mysql mysql-server php-mysql
② 启动MySQL
service mysqld start(restart|stop)
一、设置主库
1、修改主库my.cnf,主要是设置个不一样的id和logbin（#这部可依具体环境而定，压力大的化可采用huge.cnf）
[root@localhost etc]#vi /etc/my.cnf
# 记住这部分一定要配置在[mysqld]后面，否则无法找到从节点，各个配置项的含义可自己查阅文档
[mysqld]
log-bin=mysql-bin
server-id=1
binlog-ignore-db=information_schema
binlog-ignore-db=cluster
binlog-ignore-db=mysql
2、启动主库生效
[root@localhost etc]service mysqld restart
3、登陆主库
[root@localhost etc]mysql -u root -p
4、赋予从库权限帐号，允许用户在主库上读取日志
mysql> grant all privileges on *.* to '用户名'@'%' identified by '密码';
5、检查创建是否成功
select user,host from mysql.user;
6、锁主库表
mysql> flush tables with read lock;
7、显示主库信息
记录File和Position，从库设置将会用到
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 98 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
# 说明，如果执行这个步骤始终为Empty set(0.00 sec)，那说明前面的my.cnf没配置对。
8、另开一个终端登陆220，打包主库迁移数据（如果你使用的yum安装，有默认数据库并未做任何改动，则不需要进行拷贝）
目的是为了保证两台服务器的mysql数据库一致，这里可以自行tar打包或者使用mysqldump命令备份恢复的方式进行。
二、设置从库
1、传输拿到主库包、解包
# 登陆从库
从上一步中备份的数据库恢复到220服务器节点上。
2、在119节点上解锁主库表（对应第一点设置主库中第6步锁主库表的操作）
mysql> unlock tables;
3、在220节点上修改从库my.cnf（位置一样）
[root@localhost etc]vi my.cnf
# 记住这部分一定要配置在[mysqld]后面，否则无法找到从节点，各个配置项的含义可自己查阅文档
[mysqld]
log-bin=mysql-bin
server-id=2
binlog-ignore-db=information_schema
binlog-ignore-db=cluster
binlog-ignore-db=mysql
#同步的数据库为test库，其他数据库是不会同步的
replicate-do-db=test
replicate-ignore-db=mysql
log-slave-updates
slave-skip-errors=all
slave-net-timeout=60
注意：mysql5.5以下可以这样配置
master-host=192.168.2.119
master-user=root
master-password=pfingo
注意： mysql 5.5以上的配置，吧上面的master-host,master-user,master-password注释掉
replicate-do-db=database1 //同步的数据库
replicate-do-db=database2
replicate-ignore-db=mysql //被忽略的数据库
4、在220节点上验证连接主库
[root@localhost etc]mysql -h 192.168.2.119 -u 用户名 -p
5、在220节点从库上设置同步
#设置连接MASTER MASTER_LOG_FILE为主库的File，MASTER_LOG_POS为主库的Position
#注意下面第二条命令语句中的master_log_file='mysql-bin.000001', master_log_pos=98;对应为前面在主库中执行的show master status;结果
mysql> slave stop;
mysql> change master to master_host='192.168.2.119',master_user='root',master_password='pfingo',master_log_file='mysql-bin.000001', master_log_pos=98;
mysql> slave start;
6、启动从库服务
mysql> slave start;
7、进行测试
在主库上的test库上建立名为myTest的表
mysql> CREATE TABLE `myTest` (
`id` INT( 5 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
`username` VARCHAR( 20 ) NOT NULL ,
`password` CHAR( 32 ) NOT NULL ,
`last_update` DATETIME NOT NULL ,
`number` FLOAT( 10 ) NOT NULL ,
`content` TEXT NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = MYISAM ;
在从表中马上看到了效果，主从同步成功了；
为了更进一步验证在从库上输入show slave statusG;
mysql> show slave statusG;
Slave_IO_Running: Yes(网络正常)；
Slave_SQL_Running: Yes(表结构正常)
进一步验证了以上过程的正确性。
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
意思就是从上的server_id和主的一样的，经查看发现从上的/etc/my.cnf中的server_id=1这行我没有注释掉（在下面复制部分我设置了server_id），于是马上把这行注释掉了，然后重启mysql，发现还是报同样的错误。
使用如下命令查看了一下server_id
复制代码代码如下:
mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
1 row in set (0.00 sec)
发现，mysql并没有从my.cnf文件中更新server_id，既然这样就只能手动修改了
复制代码代码如下:
mysql> set global server_id=2; #此处的数值和my.cnf里设置的一样就行
mysql> slave start;
如此执行后，slave恢复了正常。
不过稍后蚊子使用/etc/init.d/mysqld restart重启了mysql服务，然后查看slave状态，发现又出现了上面的错误，然后查看server_id发现这个数值又恢复到了1。
之后蚊子又重新查看了一下/etc/my.cnf的内容，确认应该不是这个文件的问题，于是去google查了一下，看到mysql在启动的时候会查找/etc/my.cnf、DATADIR/my.cnf，USER_HOME/my.cnf。
于是我执行了
复制代码代码如下:
find / -name "my.cnf"
居然在/usr/local/mysql这个目录下发现了my.cnf文件，于是蚊子将这个文件删除了，然后再重启mysql服务，发现一切恢复了正常。如果有人也出现类似的问题，不妨试试这个办法吧。
出现Slave_IO_Running:No问题的解决方法小结
查看一下状态show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服务器show master statusG
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql错误日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228
这次是Slave_IO_Running为No，从日志上来看，服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误，这个位置不存在，于是无法同步。
查看一下这个Log的最后几行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
尝试从损坏之前的位置开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
无效！
只好从新的日志开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此时Slave_IO_Running恢复为Yes，同步进行了！观察了会儿，没有任何出错迹象，问题解决。