当执行第二代Google CloudSQL实例的PITR恢复时，恢复将失败，并显示“创build失败”错误。 除了读取日志并删除它之外，我无法操作实例克隆。
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？
我遵循的过程是执行时间点恢复 ，即我创build了一个“克隆”，并select“克隆从更早的位置”，然后指定mysql-bin.017364为“二进制日志文件名”。
编辑：设置max_allowed_packet
将原始实例上的标志max_allowed_packet设置为1073741824（1 GiB;最大值）之后，在克隆过程中，错误消息中不会再出现Got a packet bigger than 'max_allowed_packet' bytes的错误消息。 但是，CloudSQL实例仍然“无法创build”，除了现在我没有什么想法了。 操作日志说“发生了一个未知的错误”。
编辑2：
PITR操作不仅在上述情况下，而且在其他情况下也会失败。 我创build了一个独立的testing实例，并不时插入一些小行，并尝试PITR到各个时间点。
重述：与max_allowed_packet无关，与实际写入操作的大小无关PITR失败，没有任何expression性错误消息。 错误消息Got a packet bigger than 'max_allowed_packet' bytes是一个单一的重合。
– 发布最新评论作为完整性的答案。
要为您的项目和实例增加“ max_allowed_packet ”，build议打开“ 问题报告” 。
工程团队为您解决实际问题的临时解决方法是使用MySQL PITR在本地保存时间点备份。 然后，您可以使用该手动备份还原克隆实例。
通过直接使用MySQL命令，您可以为行大小指定较低的选项，以确保您处于“ max_allowed_packet ”范围内。
如果只是进行常规备份，还可以使用mysqldump命令并降低max_allowed_packer和net_buffer_length选项，以便在从备份恢复克隆时保持在强制执行的“ max_allowed_packet ”限制内。
当然，您可以直接将任意数量的其他MySQL数据库直接部署到云中，这些数据库不像云端SQL那样pipe理，正如您已经正确指出的那样。