Восстановление (PITR) CloudSQL (MySQL) завершается неудачно с получением пакета, превышающего байты 'max_allowed_packet'

При выполнении PITR-восстановления экземпляра Google CloudSQL второго поколения восстановление завершается неудачно с ошибкой "Failed to Create". Я не могу манипулировать экземпляром клона, кроме чтения журналов и его удаления.

В журнале 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.) Учитывая, что это технически является клоном экземпляра базы данных, к которому по определению уже применены те же изменения, это условие ошибки не имеет для меня особого смысла.

Как мне тогда питр?

Я выполнил процедуру восстановления на определенный момент времени, то есть я создал "клон" и выбрал "Клон с более ранней позиции", затем указал mysql-bin.017364 как "Имя двоичного файла журнала".

Редактировать: Настройкаmax_allowed_packet

После того, как я установил флаг max_allowed_packet до 1073741824 (1 ГиБ; максимальное значение) на экземпляре источника, сообщение об ошибке Got a packet bigger than 'max_allowed_packet' bytes больше не появляется в журналах ошибок при клонировании. Однако CloudSQL-Instance все еще "не удалось создать", за исключением того, что теперь у меня еще меньше идей о том, что искать. В журнале операций указано "произошла неизвестная ошибка".

Изменить 2:

Операция PITR завершается ошибкой не только с вышеуказанным экземпляром, но и с другими. Я создал независимый экземпляр для тестирования и вставляю несколько небольших строк время от времени и пытаюсь PITR к различным моментам времени.

Напомним: независимо от max_allowed_packetНезависимо от размера фактических операций записи PITR завершается неудачно, без явного сообщения об ошибке. Сообщение об ошибке Got a packet bigger than 'max_allowed_packet' bytes было единственное совпадение.

1 ответ

- Размещение последнего комментария в качестве ответа на полноту.

Чтобы увеличить max_allowed_packet для вашего проекта и экземпляра, рекомендуется открыть отчет о проблемах.

Промежуточный обходной путь, пока инженерная группа решает актуальную проблему для вас, заключается в использовании MySQL PITR для локального сохранения резервной копии на определенный момент времени. Затем вы можете восстановить экземпляр клона с помощью этой резервной копии вручную.

Используя команды MySQL напрямую, вы можете указать меньшую опцию для размера строки, чтобы убедиться, что вы находитесь внутри ' max_allowed_packet '.

Если вы просто делаете обычную резервную копию, вы также можете использовать mysqldump командовать и опустить max_allowed_packer а также net_buffer_length параметры, чтобы остаться в пределах ограничения ' max_allowed_packet ', принудительно примененного при восстановлении клона из резервной копии.


Конечно, вы всегда можете напрямую развернуть любое количество других баз данных MySQL в облаке, которые не управляются, как Cloud SQL, как вы правильно указали.

Другие вопросы по тегам