При выполнении PITR-восстановления экземпляра Google CloudSQL второго поколения восстановление завершается ошибкой «Не удалось создать». Я не могу управлять клоном экземпляра, кроме как читать журналы и удалять его.
Журнал 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 ГиБ; максимальное значение) в исходном экземпляре сообщение об ошибке 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 было странным совпадением.
- Размещение последнего комментария в качестве ответа для полноты картины.
Чтобы увеличить 'max_allowed_packet'для вашего проекта и экземпляра рекомендуется открыть Отчет о проблеме.
Временный обходной путь, пока команда инженеров устраняет реальную проблему, - использовать MySQL PITR для локального сохранения резервной копии на определенный момент времени. Затем вы можете восстановить экземпляр клона с помощью этого резервного копирования вручную.
Используя команды MySQL напрямую, вы можете указать меньший вариант для размера строки, чтобы убедиться, что вы находитесь в пределах 'max_allowed_packet'.
Если вы просто делаете обычную резервную копию, вы также можете использовать mysqldump команду и опустите max_allowed_packer и net_buffer_length варианты остаться в пределах 'max_allowed_packet'ограничение применяется при восстановлении клона из резервной копии.
Конечно ты всегда можешь напрямую развернуть любое количество других баз данных MySQL в облако, которые не управляются, как Cloud SQL, как вы правильно заметили.