我们使用googlecloudsql数据库进行复制，从三天开始，我们的主从复制就一直落后，没有赶上。
原因是什么？我们能做些什么？
我们目前所做的：
当我们意识到我们在google云中的mysql副本与主服务器不同步时，这一切就开始了。我查看了日志，发现下面的错误消息在3天前异常频繁地出现。

"2018-05-03T08:31:07.851491Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5539ms. The settings might not be optimal. (flushed=289 and evicted=0, during the time.)"

直到现在，此消息仍然出现在错误日志中。我在google上找到了这个stackoverflow线程：
如何解决mysql警告：“innodb:page\u cleaner:1000ms预期循环花费 ms。设置可能不是最佳的”？
下面提到的设置可以帮助解决这个问题innodb\u lru\u scan\u depth为256。
然而，我们的数据库是在谷歌云，在那里我们无法自定义。无法更改上述标志。
大约三天前，我们执行了一个脚本，删除了数据库中的大量数据。我假设它创建了许多“脏页面”，这些页面在我上面链接的stackoverflow线程中提到过。为了获得更多的信息，我连接到副本并发出了命令

SHOW SLAVE STATUS\G;

显示从属状态。以下是我觉得可疑的几点

***************************1. row***************************

               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: IPAdress
                  Master_User: Master
                  Master_Port: Port
                Connect_Retry: 60
              Master_Log_File: mysql-bin.021462
          Read_Master_Log_Pos: 62489170
               Relay_Log_File: relay-log.069147
                Relay_Log_Pos: 22557859
        Relay_Master_Log_File: mysql-bin.020309
             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: 22557686
              Relay_Log_Space: 121103459150
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: master_server_ca.pem
           Master_SSL_CA_Path: /mysql/datadir
              Master_SSL_Cert: replica_cert.pem
            Master_SSL_Cipher:
               Master_SSL_Key: replica_pkey.pem
        Seconds_Behind_Master: 196092
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: 3852200383
                  Master_UUID: 48880dc9-4603-11e7-8ac2-42010af01028
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 48880dc9-4603-11e7-8ac2-42010af01028:414490186-432330581
            Executed_Gtid_Set: 48880dc9-4603-11e7-8ac2-42010af01028:1-414777044,9cc92cb1-1a09-11e7-8bcc-42010af00a79:1-277822489
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.04 sec)

ERROR: No query specified

复制品落后大师196092秒，仍在上升。
据我所知：
master\u log\u文件：mysql-bin.021462显示了master的实际bin文件
中继\主\日志\文件：mysql-bin.020309显示副本的实际bin文件。
我检查了一段时间的状态，发现主日志文件比中继主日志文件上升得更快。
那是不是意味着我们的复制品永远跟不上主人？
看起来数据库正在处理中继主日志文件，但是binlogfile需要很长时间。
此外，“show processlist”表示存在指定系统锁的系统用户。

+------+-------------+----------------------------+-----------------+---------+--------+----------------------------------------+------------------------------------------------------------------------------------------------------+
| Id   | User        | Host                       | db              | Command | Time   | State                                  | Info                                                                                                 |
+------+-------------+----------------------------+-----------------+---------+--------+----------------------------------------+------------------------------------------------------------------------------------------------------+
|    1 | system user |                            | NULL            | Connect |  16023 | Queueing master event to the relay log | NULL                                                                                                 |
|    2 | system user |                            | NULL            | Connect | 196577 | System lock                            | NULL                                                                                                 |

我接下来做的是给复制品更多的cpu和内存。因为cpu的利用率是100%。服务器有8个内核和30gb内存，目前还没有得到充分利用，但仍有一半以上的资源在使用。我假设这是将脏页写入硬盘的页面清理器
我认为这可以解决我们的问题，因为在增加复制品的硬件之前，主机的功率大约是原来的四倍。但目前一切都没有改变。
页面清理器现在是否会分解脏页面，因此需要大量性能，以便副本的同步非常慢？