☰

CloudSQL (MySQL) 的恢复 (PITR) 失败，并显示数据包大于“max_allowed_pa​​cket”字节

tag-icon • tag-icon mysql restore google-cloud-sql
CloudSQL (MySQL) 的恢复 (PITR) 失败，并显示数据包大于“max_allowed_pa​​cket”字节

在对第二代 Google CloudSQL 实例进行 PITR 恢复时，恢复失败并显示“无法创建”错误。我无法操作实例克隆，只能读取日志并删除它。

mysql.err 日志显示如下消息

E  2017-10-05T14:19:39.259084Z 0 [Note] /usr/sbin/mysqld: ready for connections. 
E  Version: '5.7.14-google-log'  socket: '/mysql/mysql.sock'  port: 3306  (Google) 
E  2017-10-05T14:19:43.151623Z 3 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.017364, pos: 601), semi-sync up to file , position 0. 
E  2017-10-05T14:19:43.151666Z 3 [Note] Semi-sync replication switched OFF. 
E  2017-10-05T14:21:46.173674Z 27 [Note] Aborted connection 27 to db: 'unconnected' user: 'root' host: 'localhost' (Got a packet bigger than 'max_allowed_packet' bytes) 
E  2017-10-05T14:21:52.364195Z 2 [Note] Aborted connection 2 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets) 
E  2017-10-05T14:21:52.395075Z 7 [Note] Aborted connection 7 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets) 
E  2017-10-05T14:21:52.668786Z 29 [Note] Aborted connection 29 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets) 
E  2017-10-05T14:21:52.668816Z 28 [Note] Aborted connection 28 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets) 
E  2017-10-05T14:21:52.875975Z 0 [Note] Giving 1 client threads a chance to die gracefully 
E  2017-10-05T14:21:52.876143Z 0 [Note] Shutting down slave threads 
E  2017-10-05T14:21:54.876268Z 0 [Note] Forcefully disconnecting 1 remaining clients 
E  2017-10-05T14:21:54.876451Z 0 [Warning] /usr/sbin/mysqld: Forcing close of thread 3  user: 'root' 
E  2017-10-05T14:21:54.876479Z 0 [Note] Event Scheduler: Purging the queue. 0 events 
E  2017-10-05T14:21:54.876735Z 0 [Note] Binlog end 
E  2017-10-05T14:21:54.880101Z 0 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'

我的解释是，日志文件 17364 中的一些操作超出了范围max_allowed_package。（我的目的是恢复到日志文件 17454 中的某个点。）鉴于这在技术上是一个数据库实例的克隆，根据定义，该实例已经应用了相同的更改，因此这种错误情况对我来说没有太大意义。

那么我该如何 PITR 呢？

我遵循的程序是执行时间点恢复，即我创建了一个“克隆”并选择“从早期位置克隆”，然后指定mysql-bin.017364为“二进制日志文件名”。

编辑：设置max_allowed_packet

在我将原始实例上的标志设置max_allowed_packet为 1073741824（1 GiB；最大值）后，Got a packet bigger than 'max_allowed_packet' bytes克隆时错误消息不再出现在错误日志中。但是 CloudSQL 实例仍然“无法创建”，只是现在我更不知道该查找什么了。操作日志显示“发生未知错误”。

编辑2：

PITR 操作不仅在上述实例中失败，在其他实例中也失败。我创建了一个独立的实例进行测试，不时地插入几行小数据，并尝试 PITR 到各个时间点。

回顾一下：独立于max_allowed_packet，独立于实际写入操作的大小 PITR 失败，没有任何明确的错误消息。错误消息Got a packet bigger than 'max_allowed_packet' bytes是一次奇异的巧合。

答案1

- 发布最新评论作为答案以确保完整性。

为了增加'最大允许数据包数'对于您的项目和实例，建议打开一个问题报告。

在工程团队为您修复实际问题期间，一个临时解决方法是使用MySQL PITR在本地保存时间点备份。然后，您可以使用该手动备份恢复克隆实例。

通过直接使用 MySQL 命令，您可以指定较低的行大小选项，以确保在'最大允许数据包数“”。

如果您只是进行常规备份，您也可以使用该mysqldump命令并降低max_allowed_packer和net_buffer_length选项以保持在'最大允许数据包数'从备份恢复克隆时强制执行的限制。

当然你也可以直接部署任意数量的其他 MySQL 数据库到云端，而正如您正确指出的那样，云端的管理方式并不像 Cloud SQL 那样。

相关内容