MySQL之搭建主从架构及主从带来的问题

一、主从作用

1、实时灾备，用于故障切换。让主库极其接近从库，主库宕机，启动从库开展业务

2、实现读写分离，在从库设置只读参数

3、备份，避免影响业务

 

二、原理

1、从库启动一个线程(叫做IO线程)，连接主库

2、主库接受连接，主库为从库启动一个线程(dump线程)，读取binlog，传输到从库

3、IO线程将接受到的binlog日志写入从库的relaylog日志中(mysql-relay-bin.xxxxx)

4、从库启动一个sql apply线程读取relay log(读取完之后，自动删除)，应用binlog中的sql语句

 

注意：

1、主库的dump线程是因为从库的IO线程连接才产生。

2、要分离看io thread和sql thread

备份从库的时候，可以关闭sql thread，io thread正常运行

 

三、主从架构搭建

1、主库上建立一个账号，并在从库测试使用，为账号授权

create user backup@'172.16.11.11' identified by '123456'; grant replication slave,replication client on *.* to backup@'172.16.11.11'; mysql -ubackup -p123456 -h172.16.22.22 -P3306

2、在配置文件中，开启主库的binlog、设置server_id=1、重启mysql

3、使用xtrabackup对主库做备份，会有binlog恢复的起点

yum localinstall libev4-4.15-7.1.x86_64.rpm libev-devel-4.15-21.1.x86_64.rpm percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm perl -DBD-MySQL-4.013-3.el6.x86_64.rpm perl-DBI-1.609-4.el6.x86_64.rpm -y 

innobackupex --user=root --password=123456 --no-timestamp /backup innobackupex --apply-log /backup

cat xtrabackup_binlog_info mysqlbinlog.000008 154

4、在从库安装和主库完全一致的mysql软件，不需要初始化从库，如果已经初始化，手工删除

5、修改从库的配置文件

server_id=2
log_bin=mysqlbinlog
binlog_format=ROW或者MIXED
read_only=1 //从库只读 
binlog_rows_query_log_events=on 

6、使用scp -r将主库的备份传递到从库

scp -r ./backup [email protected]:/backup

7、在从库上执行xtrabackup进行恢复，并修改权限，启动从库

yum localinstall libev4-4.15-7.1.x86_64.rpm libev-devel-4.15-21.1.x86_64.rpm percona-xtrabackup-24-2.4.4- 1.el6.x86_64.rpm perl-DBD-MySQL-4.013-3.el6.x86_64.rpm perl-DBI-1.609-4.el6.x86_64.rpm -y 

innobackupex --copy_back /backup 

chown -R mysql:mysql /usr/local/mysql/data 

service mysql.server start

8、建立主从关系,要binlog
 

change master to master_host='172.16.22.22',master_port=3306,master_user='backup',master_password='123456',master_log_file='mysqlbinlog.000008',master_log_pos=154 ,master_connect_retry=5; start slave;

9、从库执行show processlist;查看是否io和sql线程启动

 

mysql> mysql> show processlist;
+----+-----------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
| Id | User            | Host      | db   | Command | Time  | State                                                  | Info             |
+----+-----------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
|  1 | event_scheduler | localhost | NULL | Daemon  |  1124 | Waiting on empty queue                                 | NULL             |
|  4 | root            | localhost | NULL | Query   |     0 | starting                                               | show processlist |
|  5 | system user     |           | NULL | Connect |   102 | Waiting for master to send event                       | NULL             |
|  6 | system user     |           | NULL | Connect | 86158 | Slave has read all relay log; waiting for more updates | NULL             |
+----+-----------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+

主库执行show processlist;查看是否dump线程

mysql> show processlist;
+----+-----------------+--------------------+------+-------------+------+---------------------------------------------------------------+------------------+
| Id | User            | Host               | db   | Command     | Time | State                                                         | Info             |
+----+-----------------+--------------------+------+-------------+------+---------------------------------------------------------------+------------------+
|  1 | event_scheduler | localhost          | NULL | Daemon      | 2194 | Waiting on empty queue                                        | NULL             |
|  6 | root            | localhost          | NULL | Query       |    0 | starting                                                      | show processlist |
|  7 | backup          | 172.16.11.11:54058 | NULL | Binlog Dump |  137 | Master has sent all binlog to slave; waiting for more updates | NULL             |

10、从库show slave status \G;查看io和sql线程是否有错误

 Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 

11、主库上执行dml和ddl,确认从库是否会有数据同步

主库

mysql> create database ceshi character set utf8;
Query OK, 1 row affected (0.00 sec)

mysql> use ceshi;
Database changed
mysql> create table ceshi(id int);
Query OK, 0 rows affected (0.05 sec)

mysql> insert into ceshi values(1),(2),(3);
Query OK, 3 rows affected (0.05 sec)
Records: 3  Duplicates: 0  Warnings: 0

从库数据

mysql> select * from ceshi;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+

 

四、如何切换新的binlog文件

1、重启数据库

2、手工设置最大值，默认是1G

3、手工去切binlog

flush logs;

 

五、传输延迟与应用延迟

一、传输延迟(并不是主要问题)

1、主库binlog由许多线程产生。dump线程(单线程)来不及去读取binlog.造成主库的binlog和从库的relaylog之间的差异

有可能dump线程非常繁忙，占用大量的IO，导致主库服务器的速度变慢

2、网络延迟

3、从库的IO线程没有及时写入relaylog

提高从库的写入性能，最好的办法是使用raid卡，带有写缓存

4、可以采用mixed这种方式，row可能会导致binlog暴增

 

 

增加带宽

采用mixed方式

增加物理读的能力：使用raid卡或者磁盘阵列、使用PCIe闪卡

增加写能力

使用RAID卡+写缓存。

 

二、应用延迟(日志量延迟、时间延迟)

1、当主库大量传输binlog，sql线程不断延迟，会造成relay log不断增长.io线程和sql线程之间有延迟

2、sql有问题

通过慢查询日志来确认问题(开启查询时间和全表扫描两个选项)

通过show full processlist;来捕捉

3、从库性能问题

确认从库的性能问题的时候，要配合tps和rows去看

show global status like '%rows%';

show global status like '%tps%';

不只是查看时间差距，还要查看日志量的差距

通过线程状态去确认线程是否繁忙，是否达到100%的繁忙

 

时间延迟计算：传输过来的binlog时间-正在应用的binlog时间

假设在某一个时间点出现海量的dml，可能会出现主从应用延迟(Seconds_Behind_Master越来越大)。这个时候还要看Exec_Master_Log_Pos与Read_Master_Log_Pos的差距

Slave_IO_State: Waiting for master to send event
              Master_Log_File: mysqlbinlog.000003
          Read_Master_Log_Pos: 147451558             //表示已经读到主库的binlog的位置
          
               Relay_Log_File: Client-relay-bin.000002   //表示relaylog已经跑的位置，是sql应用线程要看的
                Relay_Log_Pos: 322
                
        Relay_Master_Log_File: mysqlbinlog.000003   //relaylog的位置对应了主库上binlog的位置。表示从库已经应用到主库binlog的哪个文件
             Slave_IO_Running: Yes      //表示IO线程是否正常运行
            Slave_SQL_Running: Yes      //表示SQL线程是否正常运行
            
              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: 147451558         //表示从库已经应用的binlog的位置
              Relay_Log_Space: 530
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
        Seconds_Behind_Master: 0            //表示应用延迟落后了多少秒
Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 0  //如果IO和SQL线程欧问题，会展示出具体原因
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
               
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400