☰

掌握

tag-icon • tag-icon replication mariadb mysql-replication lag
掌握

我们首先使用功能较弱的服务器设置 MariaDB 复制，但考虑到数据库负载的增加，我们不得不租用功能更强大的服务器，而这时麻烦就开始了。

目前，主服务器和从服务器之间的复制偶尔会滞后 0 到 1000 秒，原因我们还无法确定。这种情况平均每天发生十几次。考虑到我公司的业务性质，我们根本无法承受任何滞后。

掌握

主服务器具有六核英特尔 CPU、128GB RAM、1TB SSD（采用 raid 1 配置），平均负载略高于 2，在 Ubuntu 20.04 LTS 上运行 MariaDB 10.4.2x。

在过去的大约 18 个小时中，日志中仅出现了两个与复制相关的错误/警告：

Oct 21 12:00:35 master.com mysqld[808]: 2022-10-21 12:00:35 5677386 [Warning] Aborted connection 5677386 to db: 'unconnected' user: 'replication' host: '1.2.3.4' (Got an error writing communication packets)
Oct 21 12:03:46 master.com mysqld[808]: 2022-10-21 12:03:46 5780035 [Warning] Aborted connection 5780035 to db: 'unconnected' user: 'replication' host: '1.2.3.4' (Got an error writing communication packets)

奴隶

从属服务器具有完全相同的硬件配置，并且平均负载接近 1。

MariaDB [(none)]> show slave status\G 
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: master.com
                   Master_User: replication
                   Master_Port: 3306
                 Connect_Retry: 5
              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: 133718212
               Relay_Log_Space: 133718872
               Until_Condition: None
                Until_Log_File: 
                 Until_Log_Pos: 0
         Seconds_Behind_Master: 0
                 Last_IO_Errno: 0
                 Last_IO_Error: 
                Last_SQL_Errno: 0
                Last_SQL_Error: 
   Replicate_Ignore_Server_Ids: 
              Master_Server_Id: 105
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-105-9982390796
       Replicate_Do_Domain_Ids: 
   Replicate_Ignore_Domain_Ids: 
                 Parallel_Mode: conservative
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
              Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 2226622

我们的服务器之间有 1Gbit 的连接，几乎完美。ping -f报告丢失的数据包少于 0.002％：

root@master # ping -f slave.com
PING slave.com 56(84) bytes of data.
.^C
--- slave.com ping statistics ---
71492 packets transmitted, 71491 received, 0.00139876% packet loss, time 25747ms
rtt min/avg/max/mdev = 0.239/0.339/1.941/0.066 ms, ipg/ewma 0.360/0.335 ms

我已经在互联网上搜索了该问题，但是在尝试了解根本原因或如何调试该问题方面没有找到任何令人满意的答案。

目前它正在按预期工作，但是早些时候我们遇到这个问题时我在 master 上看到了这一点：

$ SELECT * FROM information_schema.processlist WHERE User="replication"\G;
           USER: replication
           HOST: slave.com:47200
             DB: NULL
        COMMAND: Binlog Dump
           TIME: 2041
          STATE: Master has sent all binlog to slave; waiting for binlog to be updated

我不确定该怎么做。为什么“它已将所有 binlog 发送到从服务器”？为什么此时延迟会增加？有什么问题？为什么主服务器 SQL 查询未发送到从服务器？

请指教。

相关内容