Ao fazer um PITR-Restore de uma instância do Google CloudSQL de segunda geração, a restauração falha com o erro "Falha ao criar". Não consigo manipular o clone da instância, exceto ler logs e excluí-lo.
O log mysql.err mostra mensagens como
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'
Minha interpretação é que no arquivo de registro 17364 há alguma operação que excede max_allowed_package . (Minha intenção é restaurar em algum ponto no arquivo de log 17454.) Dado que isso é tecnicamente um clone de uma instância de banco de dados que, por definição, já teve as mesmas alterações aplicadas, essa condição de erro não faz muito sentido para mim.
Como faço para o PITR então?
O procedimento que segui é Realizar uma recuperação point-in-time , ou seja, criei um "clone" e escolhi "Clone da posição anterior" e, em seguida, especifiquei mysql-bin.017364 como "Nome do arquivo de log binário".
Editar: definindo max_allowed_packet
Depois de definir o sinalizador max_allowed_packet para 1073741824 (1 GiB; o valor máximo) na instância de origem, a mensagem de erro Got a packet bigger than 'max_allowed_packet' bytes não aparece mais nos logs de erros durante a clonagem. No entanto, o CloudSQL-Instance ainda "não conseguiu criar", exceto que agora tenho menos ainda uma ideia do que procurar. O log de operações diz "um erro desconhecido ocorreu".
Editar 2:
A operação PITR falha não apenas com a instância acima, mas também com outras. Eu criei uma instância independente para testar e INSERT algumas pequenas linhas de vez em quando e tente PITR para vários pontos no tempo.
Para recapitular: independentemente de max_allowed_packet , independentemente do tamanho das operações reais de gravação, o PITR falha com nenhuma mensagem de erro expressiva. A mensagem de erro Got a packet bigger than 'max_allowed_packet' bytes foi uma coincidência singular.