MySQL的主从复制步骤详解及常见错误解决方法
|
mysql主从复制(replication同步)现在企业用的比较多,也很成熟.它有以下优点: 1.降低主服务器压力,可在从库上执行查询工作. 2.在从库上进行备份,避免影响主服务器服务. 3.当主库出现问题时,可以切换到从库上. 不过,用它做备份时就会也有弊端,如果主库有误操作的话,从库也会收到命令. 下面直接进入操作.这里使用的是debian5操作系统,mysql5.0,默认引擎innodb 10.1.1.45 主库 10.1.1.43 从库 1.设置主库 1)修改主库my.cnf,这里主要是server-id一定主从不要设置成一样的.打开binlog日志 log-bin = /opt/log.bin/45 server-id = 452)在主服务器上建立同步账号 mysql> grant REPLICATION SLAVE ON *.* TO 'repl'@'10.1.1.43' IDENTIFIED BY 'replpass'; 注意:mysql的权限系统在实现上比较简单,相关权限信息主要存储在几个系统表中:mysql.user,mysql.db,mysql.host,mysql.table_priv,mysql.columm_priv.由于权限信息的数据量比较小,访问又非常频繁,所以mysql在启动的时候,就会将所有的权限信息都加载到内存中,并保存在几个特定的结构里.这就使得每次手动修改了相关权限表之后,都需要执行flush privileges,通知mysql重新加载mysql的权限信息.当然,如果通过grants,revoke或drop user 命令来修改相关权限,则不需要手动执行flush privileges命令. 3)在主服务器上导出数据库当时的快照,传给从库上. root@10.1.1.45:mysql# mysqldump -uroot -p --single-transaction --flush-logs --master-data --all-databases > all.sql --flush-logs:在导出工作开始之前先清空mysql服务器的日志文件.这样更容易恢复操作,知道在检查点时间之后创建的二进制日志文件是在备份给定数据库之后完成的.结合使用--lock-all-tables或--master-data,只有在所有数据表都锁定之后才清除日志.这个选项需要具备reload权限. --master-data:使用后mysqldump会在dump文件中产生changer master to命令,里面记录了dump时刻所对应的详细的log position信息. root@10.1.1.45:mysql# sed -n '1,40p' all.sql -- MySQL dump 10.11 -- -- Host: localhost Database: -- ------------------------------------------------------ -- Server version 5.0.51a-24+lenny1-log /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS,UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES,SQL_NOTES=0 */; -- -- Position to start replication or point-in-time recovery from -- CHANGE MASTER TO MASTER_LOG_FILE='45.000064',MASTER_LOG_POS=98; -- -- Current Database: `bbs` -- CREATE DATABASE /*!32312 IF NOT EXISTS*/ `bbs` /*!40100 DEFAULT CHARACTER SET latin1 */; USE `bbs`; -- -- Table structure for table `davehe` -- DROP TABLE IF EXISTS `davehe`; SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; CREATE TABLE `davehe` ( 2.设置从库 1).修改从库my.cnf server-id = 43 #主从可1对多 从各id不能相同 2)将主库的快照灌入从库 root@10.1.1.43:tmp# cat all.sql | mysql -uroot -p 3)在从库上设置同步.查看从库状态.
mysql> change master to master_host='10.1.1.45',master_user='repl',master_password='replpass',master_log_file='45.000064',master_log_pos=98;
Query OK,0 rows affected (0.01 sec)
mysql> start slave;
Query OK,0 rows affected (0.00 sec)
mysql> show slave statusG;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.1.1.45
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 45.000064
Read_Master_Log_Pos: 98
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 228
Relay_Master_Log_File: 45.000064
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
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: 98
Relay_Log_Space: 228
Until_Condition: None
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
1 row in set (0.00 sec)
ERROR:
No query specified
测试OK 当然这只是最简单的配置 还有很多参数可根据环境需求变化. 比如
mysql数据库同步跳过临时错误 stop slave; set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; (事务类型,可能需要执行几次) start slave; stop slave IO_THREAD //此线程把master段的日志写到本地 start slave IO_THREAD stop slave SQL_THREAD //此线程把写到本地的日志应用于数据库 start slave SQL_THREAD Slave_IO_Running: No错误 由于主库的主机192.168.1.1宕机,再次启来后,从库192.168.71.1连接主库发现报错. Slave_IO_Running: No
root@192.168.71.1:~# mysql -uroot -p --socket=/opt/mysql/3399/3399.sock
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 452723
Server version: 5.0.51a-24+lenny2 (Debian)
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> show slave statusG;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.1.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 99.000302
Read_Master_Log_Pos: 165112917
Relay_Log_File: 3399-relay-bin.000013
Relay_Log_Pos: 165113047
Relay_Master_Log_File: 99.000302
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
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: 165112917
Relay_Log_Space: 165113047
Until_Condition: None
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: NULL
1 row in set (0.00 sec)
mysql@192.168.71.1:/opt/mysql/3399$ cat 192.168.71.1.err 140115 1:51:01 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 140115 1:51:01 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log 140115 1:51:01 [Note] Slave I/O thread exiting,read up to log '99.000302',position 165112917
root@192.168.1.1:mysql.bin# mysqlbinlog 99.000302 > /tmp/test root@192.168.1.1:mysql# tail -n 10 /tmp/test #140115 0:50:25 server id 1176 end_log_pos 165111351 Query thread_id=111 exec_time=0 error_code=0 SET TIMESTAMP=1389718225/*!*/; INSERT INTO user_info_db_86.region_info_table_56 (userid,region,gameflag) VALUES (563625686,2) ON DUPLICATE KEY UPDATE gameflag = (gameflag | 2)/*!*/; # at 165111351 #140115 0:50:25 server id 1176 end_log_pos 165111378 Xid = 17877752 COMMIT/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; 结果发现主库上位置最后是165111351 比165112917要小. 也就是从库同步找的位置比主库要大,故同步不成功 (编辑:安卓应用网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
