mysql复制是将主数据库的DDL和DML操做经过二进制日志传到复制服务器(也叫从服务器)上,而后在从服务器上对这些日志从新执行(也叫重作),从而使从服务器和猪服务器的数据保持同步。
mysql复制的优势主要包括如下3个方面:
1)若是主服务器出现问题,能够快速切换到从服务器提供服务。
2)能够在从服务上执行查询操做,下降主服务器的访问压力。只有更新不频繁的数据和对实时性要求不高的数据能够经过从服务器查询。
3)能够在从服务器上执行备份,以免备份期间影响主服务器的服务。
1、安装配置。
确保主从服务器安装相同版本的mysql,推荐安装最新稳定版本。
1. 在主服务器上设置一个复制使用的帐户,并授予REPLICATION SLAVE 权限,这里建立一个复制用户repl 能够从ip为172.16.27.21的主机进
行链接:
引用
mysql>GRANT REPLICATION SLAVE ON * . * TO 'repl' @ ' 172.16.27.21' IDENTIFIED BY '123456';
2. 修改主服务器的my.cnf文件 开启binlog 并设置server-id值。这两个参数须要重启mysql才能生效。
引用
[mysqld]
log-bin = mysql-bin
server-id =1
3. 而后在主数据上设置读锁定有效,这个操做是为了确保没有数据库操做,以便获取得一个一致性快照。
引用
mysql> flush tables with read lock;
4. 而后获得住数据库当前二进制日志名和偏移量值。这个操做的目的是为了从数据库启动后从这个点开始进行数据的恢复。
引用
mysql > show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000069 | 194548 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
5. 将主数据库备份恢复到从数据库上,主数据库能够恢复写操做,剩下的操做只须要在从数据库执行;
引用
mysql > unlock tables;
6. 修改从数据库的配置文件my.cnf 增长server-id 参数 注意server-id的值必须是惟一的不能和主服务器配置相同。若是有多个从服务器每
个从服务器必须有本身惟一的server-id值。
引用
[mysqld]
server-id = 2
#使从服务器把复制的事件记录到本身的二进制日志中
log_slave_updates = 1
master-host = 172.16.27.23
master-port = 3306
master-user = repl
master-password = 123456
replicate-do-db = my_blog
7.在从服务上使用--skip-slave-start 选项启动从数据库,这样不会当即启动从数据库上的复制进程,方便咱们对从数据库的服务进行进一步
的配置制定从服务器开始执行复制的日志文件和位置:
引用
/usr/local/mysql/bin/mysqld_safe --skip-slave-start &
引用
mysql> CHANGE MASTER TO
-> MASTER_LOG_FILE='mysql-bin.000069',
-> MASTER_LOG_POS=194548;
Query OK, 0 rows affected (0.02 sec)
8. 从服务器上启动slave线程
9. 查看从服务器状态
引用
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.27.23
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000069
Read_Master_Log_Pos: 194548
Relay_Log_File: test-relay-bin.000002
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000069
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: my_blog
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: 194548
Relay_Log_Space: 405
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
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)
在显示的信息中,咱们主要关注Slave_IO_Running 和Slave_SQL_Running 这两个线程的状态是不是yes 这两个线程的含义分别以下:
Slave_IO_Running 此线程负责从服务器从主服务器上读取binlog日志,并写入从服务器上的中继日志中
Slave_SQL_Running 此线程负责读取并执行中继日志中的binlog日志,
只要其中有一个状态时no ,则表示复制线程中止,错误缘由能够从Last_Errno字段的值中看到。
2、主从服务器同步维护。
在某些繁忙的OLTP(在线事物处理)系统上,因为主服务器更新频繁,而从服务器因为各类缘由致使更新速度较慢,从而使主从服务器之间的数据差距愈来愈大,在这种状况下,咱们就须要按期的进行主从服务器的数据同步,使得主从数据差距能减小到最小,经常使用的方法是在负载较低的时候阻塞主数据库的更新,强制主从数据库更新同步。
1.在主服务器上 执行如下语句(注意,会阻塞主数据库的全部更新操做)
引用
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000069 | 226897 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
记录show 语句的输出日志名和偏移量,这些是从服务器复制的目的坐标。
2. 在从服务器上执行下面的语句.
引用
mysql> select MASTER_POS_WAIT('mysql-bin.000069',' 226897 ');
+----------------------------------------------+
| MASTER_POS_WAIT('mysql-bin.000069',' 226897 ') |
+----------------------------------------------+
| 0 |
+----------------------------------------------+
1 row in set (0.01 sec)
其中MASTER_POS_WAIT()函数的参数就是前面的步骤中获得的复制坐标值。这个select 语句会阻塞直到从服务器达到指定的日志文件和偏移量后返回0 若是返回-1则表示超时退出,查询返回0时则从服务器与主服务器同步。
3. 在主服务器上执行下面的语句容许主服务器从新开始处理更新。
引用
mysql>UNLOCK TABLES; Query OK, 0 rows affected (0.00 sec)