专职DBA-MySQL主从延迟复制

专职DBA-MySQL主从延迟复制

本次实验环境延用MySQL主从异步复制的搭建环境

mysql集群企业级架构方案
1.根据对数据库的访问请求实现读写分离(读从写主)
2.根据不同的业务拆分多个从库以提供访问
    一主五从
    3从提供外部用户读请求访问(读写分离、LVS负载均衡)
    1从用于内部用户读访问(业务后台、数据分析、搜索业务、财务统计、定时任务、开发查询等)
    1从用于数据库定时全备份,以及增量备份(开启binlog)
3.实现对主库的高可用
    (1).heartbeat+dbrd+mysql方案
            通过dbrd工具对主数据库服务器实现基于block的异机物理复制,类似于网络RAID1.
            优点:速度很快。
            缺点:不能被访问,除非主节点宕机,备节点才可以提供访问。
    (2).mysql-MMM(Master-Master replication Manager)方案
            通过mysql的replication实现主主之间的数据同步。
            优点:可以实现slaves负载均衡。
            缺点:MMM无法完全保持数据的一致性。
    (3).mysql-MHA(Master High Availability)+keepalived方案
            通过mysql的replication实现数据库服务器之间的数据同步。
            优点:同时可以实现从库负载均衡,主库宕机后自动选择最优的从库,将其切换为主库。
                  并尽最大的努力对有所有的库做数据补全操作,一直到最新。
                  并对其他从库和新主库实现复制,再加上keepalived是为了实现vip漂移。
    (4).PXC
    (5).共享存储方案
    (6).数据库分布式部署方案
    (7).MGR

mysql企业级备份策略方案
1.利用mysql主从复制的从库进行数据备份策略
(1).选择一个不对外提供服务的从库,专门做数据备份用。
(2).开启从库的binlog功能。
(3).数据量小于30GB用mysqldump逻辑备份;
     数据库大于30GB用Xtrabackup物理热备工具。

mysql主从复制生产环境的常见延迟原因
易导致复制延迟的原因:
    1.一个主库的从库太多
    2.从库硬件比主库查
    3.慢sql语句过多
    4.主从复制的设计问题
    5.主从复制之间的网络延迟
    6.主库读写压力太大

mysql主从复制数据一致性企业级方案
1.采用半同步复制方案
2.当复制发生延迟时让程序改读主库

mysql多线程复制解决复制延迟实践
[[email protected] ~]# mysqld --defaults-file=/data/mysql/3306/my.cnf &
[[email protected] ~]# mysqld --defaults-file=/data/mysql/3306/my.cnf &

(1).查看当前slave服务器的SQL线程状态
[[email protected] ~]# mysql -S /data/mysql/3306/mysql.sock -p
Enter password:

Slave [(none)]> show processlist;
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
| Id | User        | Host      | db   | Command | Time | State                                                  | Info             |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
|  1 | system user |           | NULL | Connect |   49 | Waiting for master to send event                       | NULL             |
|  2 | system user |           | NULL | Connect |   48 | Slave has read all relay log; waiting for more updates | NULL             |
|  4 | root        | localhost | NULL | Query   |    0 | starting                                               | show processlist |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

(2).检查多线程的参数配置
默认为0表示单线程复制
Slave [(none)]> show variables like "%parallel%";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| slave_parallel_type    | DATABASE |
| slave_parallel_workers | 0        |
+------------------------+----------+
2 rows in set (0.01 sec)

(3).停止主从复制,在线修改线程数
Slave [(none)]> stop slave;
Query OK, 0 rows affected (0.00 sec)

Slave [(none)]> set global slave_parallel_workers = 4;
Query OK, 0 rows affected (0.00 sec)

Slave [(none)]> show variables like "%parallel%";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| slave_parallel_type    | DATABASE |
| slave_parallel_workers | 4        |
+------------------------+----------+
2 rows in set (0.00 sec)

(4).启动主从复制,查看SQL线程数
Slave [(none)]> start slave;
Query OK, 0 rows affected (0.04 sec)

Slave [(none)]> show processlist;
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
| Id | User        | Host      | db   | Command | Time | State                                                  | Info             |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
|  4 | root        | localhost | NULL | Query   |    0 | starting                                               | show processlist |
|  5 | system user |           | NULL | Connect |   28 | Waiting for master to send event                       | NULL             |
|  6 | system user |           | NULL | Connect |   28 | Slave has read all relay log; waiting for more updates | NULL             |
|  7 | system user |           | NULL | Connect |   28 | Waiting for an event from Coordinator                  | NULL             |
|  8 | system user |           | NULL | Connect |   28 | Waiting for an event from Coordinator                  | NULL             |
|  9 | system user |           | NULL | Connect |   28 | Waiting for an event from Coordinator                  | NULL             |
| 10 | system user |           | NULL | Connect |   28 | Waiting for an event from Coordinator                  | NULL             |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+
7 rows in set (0.00 sec)

(5).想永久生效就写入my.cnf
[[email protected] ~]# vim /data/mysql/3306/my.cnf
[mysqld]
slave_parallel_workers = 4

让mysql主从复制的从库只读访问
1.read-only参数允许数据库更新的条件
(1).具有super权限的用户可以更新,不受read-only参数影响。例如:root
(2).来自从服务器具备主从复制权限的线程可以更新,不受read-only参数的影响。例如:rep
2.如何配置read-only参数
(1).启动数据库时直接带--read-only参数启动。
mysqld_safe --read-only --user=mysql &
(2).在my.cnf文件中配置
[[email protected] ~]# vim /data/mysql/3306/my.cnf
[mysqld]
read-only

然后重启数据库
mysqladmin -S /data/mysql/3306/mysql.sock -p shutdown
mysqld --defaults-file=/data/mysql/3306/my.cnf &

mysql主从复制读写分离Web用户生产设置方案
在配置好mysql主从复制,并实现了读写分离以后,数据库授权程序访问的用户设置方法:
1.主库和从库使用不同的用户,授予不同的权限。
    主库上对web_w用户的授权
    grant select,insert,update,delete on `web`.* to ‘web_w‘@‘192.168.10.%‘ identified by ‘123‘;

    从库上对web_r用户的授权
    grant select on `web`.* to ‘web_r‘@‘192.168.10.%‘ identified by ‘123‘;

2.网站程序访问主库和从库时使用一套用户密码。
(1).主库和从库使用相同的用户,但授予不同的权限。
忽略主库的mysql授权库同步
[[email protected] ~]# vim /data/mysql/3306/my.cnf
binlog-ignore-db = mysql     #mysql库不记录binlog日志
replicate-ignore-db = mysql  #忽略复制mysql库

在主库上创建完web用户和权限之后,在从库上revoke回收对应的更新权限
主库:grant select,insert,update,delete on `web`.* to ‘web‘@‘192.168.10.%‘ identified by ‘123‘;
从库:grant select on `web`.* to ‘web‘@‘192.168.10.%‘ identified by ‘123‘;

在从库上设置read-only参数,让从库只读
[[email protected] ~]# vim /data/mysql/3306/my.cnf
[mysqld]
read-only
然后重启数据库
mysqladmin -S /data/mysql/3306/mysql.sock -p shutdown
mysqld --defaults-file=/data/mysql/3306/my.cnf &

mysql主从延迟复制方案及恢复实践
[[email protected] ~]# mysql -S /data/mysql/3306/mysql.sock -p
Enter password:

Slave [(none)]> stop slave;
Query OK, 0 rows affected (0.01 sec)

Slave [(none)]> change master to master_delay = 60;
Query OK, 0 rows affected (0.01 sec)

Slave [(none)]> start slave;
Query OK, 0 rows affected (0.02 sec)

Slave [(none)]> show slave status\G
*************************** 1. row ***************************
                    SQL_Delay: 60 #延迟60秒进行复制
          SQL_Remaining_Delay: NULL #还剩多少秒执行复制
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates #sql线程状态

[[email protected] ~]# mysql -S /data/mysql/3306/mysql.sock -p
Enter password:

Master [(none)]> create database app;
Query OK, 1 row affected (0.00 sec)

Master [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
6 rows in set (0.00 sec)

Slave [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
5 rows in set (0.01 sec)

但是中继日志里面已经有创建的语句了,说明IO线程还是实时在工作的。
[[email protected] ~]# cd /data/mysql/3306/data/
[[email protected] /data/mysql/3306/data]# ls -l
total 122952
-rw-r----- 1 mysql mysql       56 Jul 15 05:52 auto.cnf
-rw-r----- 1 mysql mysql      206 Jul 16 01:43 db02-relay-bin.000001
-rw-r----- 1 mysql mysql      476 Jul 16 01:47 db02-relay-bin.000002
-rw-r----- 1 mysql mysql       48 Jul 16 01:43 db02-relay-bin.index
-rw-r----- 1 mysql mysql      599 Jul 15 06:54 ib_buffer_pool
-rw-r----- 1 mysql mysql 12582912 Jul 16 01:23 ibdata1
-rw-r----- 1 mysql mysql 50331648 Jul 16 01:23 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Jul 15 05:52 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 Jul 16 01:23 ibtmp1
-rw-r----- 1 mysql mysql      122 Jul 16 01:48 master.info
drwxr-x--- 2 mysql mysql     4096 Jul 15 06:35 mysql
drwxr-x--- 2 mysql mysql     8192 Jul 15 05:52 performance_schema
-rw-r----- 1 mysql mysql       59 Jul 16 01:43 relay-log.info
drwxr-x--- 2 mysql mysql       48 Jul 15 06:50 shenzhen
drwxr-x--- 2 mysql mysql     8192 Jul 15 05:52 sys
-rw-r----- 1 mysql mysql       84 Jul 16 01:43 worker-relay-log.info.1
-rw-r----- 1 mysql mysql       84 Jul 16 01:43 worker-relay-log.info.2
-rw-r----- 1 mysql mysql       84 Jul 16 01:43 worker-relay-log.info.3
-rw-r----- 1 mysql mysql       84 Jul 16 01:43 worker-relay-log.info.4

[[email protected] /data/mysql/3306/data]# mysqlbinlog db02-relay-bin.000002
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
create database app
/*!*/;

过了1分钟后
Slave [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
6 rows in set (0.00 sec)

mysql的延迟复制实际上影响的只是SQL线程将数据应用到从库。
而IO线程早已把主库更新的数据写到了从库的中继日志里面。
因此,在延迟复制期间,即使主库宕机了,从库到了延迟复制的时间,也依然会把数据更新到与主库宕机时一致。

使用mysql主从延迟复制进行数据恢复实践
1.模拟环境,将从库延迟调整为3600秒
[[email protected] ~]# mysql -S /data/mysql/3306/mysql.sock -p
Enter password:

Slave [(none)]> stop slave;
Query OK, 0 rows affected (0.01 sec)

[[email protected] ~]# mysql -u root -p -S /application/mysql/tmp/mysql.sock
Enter password:

mysql> stop slave ;
Query OK, 0 rows affected (0.00 sec)

Slave [(none)]> change master to master_delay = 3600;
Query OK, 0 rows affected (0.02 sec)

Slave [(none)]> start slave;
Query OK, 0 rows affected (0.03 sec)

Slave [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.11
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000005
          Read_Master_Log_Pos: 350
               Relay_Log_File: db02-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000005
             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: 350
              Relay_Log_Space: 526
              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:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 113306
                  Master_UUID: 7c145945-a680-11e9-baea-000c29a14cf7
             Master_Info_File: /data/mysql/3306/data/master.info
                    SQL_Delay: 3600
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: 7c145945-a680-11e9-baea-000c29a14cf7:1-4
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

2.模拟在主库写入数据,每隔5秒写入一个库,就当是模拟用户写入数据了
for n in {01..05}
do
    mysql -S /data/mysql/3306/mysql.sock -p123 -e "create database app$n;"
    sleep 5
done

[[email protected] ~]# for n in {01..05}
> do
>     mysql -S /data/mysql/3306/mysql.sock -p123 -e "create database app$n;"
>     sleep 5
> done
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
[[email protected] ~]#

3.模拟人为破坏数据,也可以是不带where的update语句。
Master [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| app01              |
| app02              |
| app03              |
| app04              |
| app05              |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
11 rows in set (0.00 sec)

删除oldboy5数据库,后面要做的就是把这个数据库恢复回来,别的数据还得保留。
Master [(none)]> drop database app05;
Query OK, 0 rows affected (0.01 sec)

Master [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| app01              |
| app02              |
| app03              |
| app04              |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
10 rows in set (0.00 sec)

Master [(none)]> drop database app05;
Query OK, 0 rows affected (0.01 sec)

Master [(none)]> show databases like "%app%";
+------------------+
| Database (%app%) |
+------------------+
| app              |
| app01            |
| app02            |
| app03            |
| app04            |
+------------------+
5 rows in set (0.00 sec)

现在,所有的从库都已经是坏数据了,只有延迟从库是好的,但是是一个小时之前的数据。

4.当数据库出现误删数据的情况时,特别是update不加条件破坏数据,要想完整恢复数据,最好选择对外停止访问措施,此时需要牺牲用户体验了。
[[email protected] ~]# iptables -I INPUT -p tcp --dport 3306 ! -s 192.168.10.13 -j DROP
非192.168.10.13禁止访问数据库3306端口,11是主库IP,192.168.10.13为远程连接ssh客户端的IP。

5.登录主库从库查看binlog发送接收进行确认。
Master [(none)]> show processlist;
+----+------+---------------------+------+-------------+------+---------------------------------------------------------------+------------------+
| Id | User | Host                | db   | Command     | Time | State                                                         | Info             |
+----+------+---------------------+------+-------------+------+---------------------------------------------------------------+------------------+
|  5 | root | localhost           | NULL | Query       |    0 | starting                                                      | show processlist |
|  6 | rep  | 192.168.10.12:39828 | NULL | Binlog Dump |  754 | Master has sent all binlog to slave; waiting for more updates | NULL             |
+----+------+---------------------+------+-------------+------+---------------------------------------------------------------+------------------+
2 rows in set (0.00 sec)

从库
Slave [(none)]> show processlist;
+----+-------------+-----------+------+---------+------+----------------------------------------------------------------+------------------+
| Id | User        | Host      | db   | Command | Time | State                                                          | Info             |
+----+-------------+-----------+------+---------+------+----------------------------------------------------------------+------------------+
| 20 | root        | localhost | NULL | Query   |    0 | starting                                                       | show processlist |
| 21 | system user |           | NULL | Connect |  789 | Waiting for master to send event                               | NULL             |
| 22 | system user |           | NULL | Connect |  228 | Waiting until MASTER_DELAY seconds after master executed event | NULL             |
| 23 | system user |           | NULL | Connect |  789 | Waiting for an event from Coordinator                          | NULL             |
| 24 | system user |           | NULL | Connect |  789 | Waiting for an event from Coordinator                          | NULL             |
| 25 | system user |           | NULL | Connect |  789 | Waiting for an event from Coordinator                          | NULL             |
| 26 | system user |           | NULL | Connect |  789 | Waiting for an event from Coordinator                          | NULL             |
+----+-------------+-----------+------+---------+------+----------------------------------------------------------------+------------------+
7 rows in set (0.00 sec)

Slave [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
6 rows in set (0.00 sec)

6.在从库上停止主从复制,并查看数据库是否已同步过来。
Slave [(none)]> stop slave;
Query OK, 0 rows affected (0.01 sec)

Slave [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
6 rows in set (0.00 sec)
因为还未到延迟时间,所以数据不会同步到该延迟从库。

7.根据relay-log.info记录的sql线程读取relay-log的位置,解析未应用到从库的relay-bin日志。
进入中继日志所在的目录
[[email protected] ~]# cd /data/mysql/3306/data/
[[email protected] /data/mysql/3306/data]# ls -l
total 122952
drwxr-x--- 2 mysql mysql       20 Jul 16 01:48 app
-rw-r----- 1 mysql mysql       56 Jul 15 05:52 auto.cnf
-rw-r----- 1 mysql mysql      206 Jul 16 01:55 db02-relay-bin.000001
-rw-r----- 1 mysql mysql     1282 Jul 16 02:05 db02-relay-bin.000002
-rw-r----- 1 mysql mysql       48 Jul 16 01:55 db02-relay-bin.index
-rw-r----- 1 mysql mysql      599 Jul 15 06:54 ib_buffer_pool
-rw-r----- 1 mysql mysql 12582912 Jul 16 01:49 ibdata1
-rw-r----- 1 mysql mysql 50331648 Jul 16 01:49 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Jul 15 05:52 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 Jul 16 01:23 ibtmp1
-rw-r----- 1 mysql mysql      123 Jul 16 02:09 master.info
drwxr-x--- 2 mysql mysql     4096 Jul 15 06:35 mysql
drwxr-x--- 2 mysql mysql     8192 Jul 15 05:52 performance_schema
-rw-r----- 1 mysql mysql       61 Jul 16 02:09 relay-log.info
drwxr-x--- 2 mysql mysql       48 Jul 15 06:50 shenzhen
drwxr-x--- 2 mysql mysql     8192 Jul 15 05:52 sys
-rw-r----- 1 mysql mysql       84 Jul 16 01:55 worker-relay-log.info.1
-rw-r----- 1 mysql mysql       84 Jul 16 01:55 worker-relay-log.info.2
-rw-r----- 1 mysql mysql       84 Jul 16 01:55 worker-relay-log.info.3
-rw-r----- 1 mysql mysql       84 Jul 16 01:55 worker-relay-log.info.4

[[email protected] /data/mysql/3306/data]# ls -l *relay*
-rw-r----- 1 mysql mysql  206 Jul 16 01:55 db02-relay-bin.000001 中继日志
-rw-r----- 1 mysql mysql 1282 Jul 16 02:05 db02-relay-bin.000002 中继日志
-rw-r----- 1 mysql mysql   48 Jul 16 01:55 db02-relay-bin.index 中继日志索引
-rw-r----- 1 mysql mysql   61 Jul 16 02:09 relay-log.info 线程读取中继日志的位置信息
-rw-r----- 1 mysql mysql   84 Jul 16 01:55 worker-relay-log.info.1
-rw-r----- 1 mysql mysql   84 Jul 16 01:55 worker-relay-log.info.2
-rw-r----- 1 mysql mysql   84 Jul 16 01:55 worker-relay-log.info.3
-rw-r----- 1 mysql mysql   84 Jul 16 01:55 worker-relay-log.info.4

[[email protected] /data/mysql/3306/data]# cat relay-log.info
7
./db02-relay-bin.000002  #SQL线程读取中继日志的文件名信息
320                          #SQL线程读取中继日志的位置点信息
mysql-bin.000005
350
3600
4
1

8.解析SQL线程未解析的全部剩余relay-bin中继日志数据。
[[email protected] /data/mysql/3306/data]# mysqlbinlog --start-position=320 db02-relay-bin.000002 > /backup/sql/relay.sql

[[email protected] /data/mysql/3306/data]# mysqlbinlog --skip-gtids --start-position=320 db02-relay-bin.000002 > /backup/sql/relay.sql

[[email protected] ~]# ls -l /backup/sql/relay.sql
-rw-r--r-- 1 root root 3688 Jul 16 02:15 /backup/sql/relay.sql

9.找到破坏数据库的SQL语句,并从已解析的SQL语句中将其删除掉,这里使用的是"drop database app05"
[[email protected] ~]# egrep "drop database app05" /backup/sql/relay.sql
drop database app05
[[email protected] ~]# sed -i ‘/drop database app05/d‘ /backup/sql/relay.sql
[[email protected] ~]# egrep "drop database app05" /backup/sql/relay.sql
[[email protected] ~]# egrep "^drop database app05" /backup/sql/relay.sql

10.将解析后并处理好的relay.sql数据文件恢复到延迟从库。
[[email protected] ~]# mysql -S /data/mysql/3306/mysql.sock -p < /backup/sql/relay.sql
Enter password:

Slave [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| app                |
| app01              |
| app02              |
| app03              |
| app04              |
| app05              |
| mysql              |
| performance_schema |
| shenzhen           |
| sys                |
+--------------------+
11 rows in set (0.00 sec)

之前的删除的app05数据库已经恢复找回来了!!!

利用延迟从库恢复数据库完毕,此时还需要将此从库切换为主库,作为新主库对外提供用户访问。再对其他遭到破坏的主从数据库进行修复。
-------------------------------------------------------->OK

Slave [(none)]> start slave;
Query OK, 0 rows affected (0.01 sec)

Master [shenzhen]> use shenzhen;
Database changed
Master [shenzhen]> insert into t1(id) values(2);
Query OK, 1 row affected (0.01 sec)

Master [shenzhen]> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

Slave [(none)]> stop slave;
Query OK, 0 rows affected (0.02 sec)

Slave [(none)]> change master to master_delay = 20;
Query OK, 0 rows affected (0.01 sec)

Slave [(none)]> start slave;
Query OK, 0 rows affected (0.03 sec)

Slave [(none)]> select * from shenzhen.t1;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

原文地址:https://www.cnblogs.com/zhouwanchun/p/11190634.html

时间: 2024-10-13 09:02:05

专职DBA-MySQL主从延迟复制的相关文章

MySQL主从延迟复制实践及生产故障案例恢复实践

1.1 MySQL主从延迟复制介绍 从MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是数据库数据量很大时,恢复时间会很长,再恢复期间数据库数据被删或错误数据影响正常的访问体验. 而延迟复制就可以较好的解决这个问题.例如,可以设定某一个从库和主库的更新延迟1小时,这样主库数据出问题以后,1个小时以内发现,可以对这个从库进行无害恢复处理,使之依

MySQL 主从延迟复制方法总结

mysql 5.6开始已经支持主从延迟复制,可设置从库延迟的时间.延迟复制的意义在于:主库误删除对象时,在从库可以查询对象没改变前状态. 方法介绍 1.percona公司pt-slave-delay工具 主库: [[email protected] ~]$ login Logging to file '/tmp/master.log' Warning: Using a password on the command line interface can be insecure. Welcome

实时刷新缓存-处理mysql主从延迟的一些设计方案

概要: 在项目开发当中,经常有这样一种场景,对数据库进行添加.修改.删除操作的应用直接连接master库,只对数据库进行查询的应用,会先建立一个中央缓 存,例如redis或者memcache,如果缓存没有命中,那么直接访问slave库.下文会介绍一下在刷新中央缓存时,如果发生主从延迟,应该如何处 理.也即是,当应用System-A 把数据库写入master库的时候,System-B应用在读取slave库的时候,master库的数据还没同步到slave库,如果这个时候刷新缓存 的话,会直接把旧的数

MySQL主从延迟现象及原理分析详解

一.现象 凌晨对线上一张表添加索引,表数据量太大(1亿+数据,数据量50G以上),造成主从延迟几个小时,各个依赖从库的系统无法查询数据,最终影响业务. 现在就梳理下主从延迟的原理. 二.原理 根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述,MySQL 主从复制依赖于三个线程:一个线程(),两个线程(和).主从复制流程如下图: master 服务器和 slave 服务器连接时,创建以发送数据: 一个对应一个 slave 服务器

MySQL主从延时复制

MySQL的主从复制是实现MySQL大规模集群的基础,其在日常生产环境中被广泛的被应用,而在MySQL5.6开始对MySQL的底层代码不断的重构完善后在MySQL的主从复制取得极大的进步,且在5.7版本引入主从多线程复制(http://blog.51cto.com/jim123/1961241),而在5.6版本开始MySQL的主从复制就支持slave上延时复制master而不需要借助第三方工具实现,主从复制延时可以在master误删除数据后在slave中延时一定时间后快速找回误删除数据,至于设置

MySQL 主从延迟几万秒 Queueing master event to the relay log(转)

数据库版本Server version:    5.6.24-log Source distribution 问题描述 数据采集平台业务数据库由于批量灌数据导致主从延迟上万秒. 复制线程长期处于Queueing master event to the relay log状态. 监控数据显示1.Seconds_Behind_Master 维持在6w秒左右,且有上升趋势.2.主库有大量的binlog积压无法同步到从库,但主从库的网卡流量都很低远未达到瓶颈.3.从库的qps与tps很低,维持在几百左右

mysql主从数据库复制

Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收从那时起发生的

mysql 主从的复制的原理及操作步骤

数据库读法约定: 主库: master 从库: slave mysql 主从同步的原理: #主从是异步模式,且是由从库找主库进行同步: 1.主库开启IO线程:    开启binlog: #binlog记录用户的增删改 从库开启IO线程:    开启SQL线程: 2.主库授权从库同步的帐号密码: 3.备份主库数据且导入从库: 4.在从库change master to 导入用于同步主库的ip.port.user.等信息. CHANGE MASTER TO          MASTER_HOST=

mysql主从服务器复制原理

在实际企业应用环境当中,单台mysql数据库是不足以满足日后业务需求的.譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止.介于这种情况,我们来学习一下mysql主从复制. 将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服