Kubectl exec останавливается/закрывается через 2-3 минуты
Я пытаюсь сделать резервную копию базы данных MySQL, работающей внутри кластера k8s (k3s). Этот кластер работает локально на Raspberry Pi. Я создал собственный образ на основе Alpine Linux, который содержит скрипт для создания резервной копии с помощью mysqldump:
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> > <file_name>
Когда я запускаю команду mysqldump из модуля базы данных, она успешно завершается через 10-15 секунд. Но когда эта команда выполняется внутри модуля Alpine, это почему-то занимает намного больше времени (2 минуты 40 секунд). В этот момент он останавливает/прерывает команду kubectl exec (из-за тайм-аута?), и скрипт загружает поврежденный файл sql, потому что команда mysqldump не была завершена с резервным копированием.
Ожидаемый подробный вывод:
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table user...
-- Sending SELECT query...
-- Retrieving rows...
-- Disconnecting from localhost...
Получил подробный вывод:
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
У меня есть 2 вопроса:
- Почему команда mysqldump в модуле Alpine выполняется намного дольше, чем в модуле базы данных?
- Почему команда kubectl exec не ждет, пока команда mysqldump завершит создание резервной копии? Почему вдруг решает, что пора отключиться и двигаться дальше?
Они оба не имеют явного распределения ресурсов. Однако свободных ресурсов более чем достаточно, если оба этих модуля заняты резервным копированием. Они оба остаются здоровыми (без перезапусков). В alpine pod не установлен драйвер базы данных. Он просто запускается в модуль db и запускает там команду mysqldump.
Ответы 1
Возможно, вы отключаетесь, потому что kubectl считает, что соединение разорвано из-за отсутствия данных с другой стороны.
Вместо:
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> > <file_name>
Пытаться:
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> | tee <file_name>
Вместо этого он будет выводиться на стандартный вывод, а также отправляться в файл. Это гарантирует, что kubectl увидит возвращающиеся данные и не отключит вас, если это проблема отсутствия данных. Недостатком этого является то, что вы получаете все данные SQL, которые перекачиваются к вам на стандартный вывод.
Другая альтернатива (и которую я бы лично рекомендовал) — это установить что-то вроде screen или tmux или другого терминального мультиплексора и сделать в нем дамп, чтобы вы могли отключиться от модуля и не беспокоиться о том, что kubectl отключит вас.
Обновлено: Просто чтобы уточнить, я имел в виду установку мультиплексора внутри модуля (например, внутри образа докера, который вы используете для создания модуля)
Кажется, это мешает kubectl отключиться. Процесс резервного копирования по-прежнему занимал слишком много времени, поэтому я установил mysqlsump на образ alpine и сделал удаленное резервное копирование.
Да, вывод потока sql на стандартный вывод замедлит резервное копирование, поэтому предлагается использовать мультиплексор.
Оба модуля имеют одинаковое распределение памяти/процессора? И остаются ли оба модуля работоспособными во время выполнения этой команды? Использует ли Alpine Pod ту же базу данных/драйвер?