Восстановление (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, как вы правильно указали.