MySQL Cluster ndb_restore завершается с ошибкой без ошибок
Я работал над переносом нашей текущей единой базы данных в новую кластерную базу данных, работающую под кластером MySQL.
Это большая база данных (несколько миллиардов записей), и, хотя она, кажется, работает достаточно хорошо, мне трудно восстановить резервную копию (для второй реплики разработки сайта)
Резервная копия содержит только около 800 миллионов отчетов, с которыми оборудование должно справиться. Тем не менее, когда я пытаюсь восстановить резервную копию (что может занять от нескольких часов до нескольких дней!), Некоторые узлы восстанавливаются просто останавливаются - без видимой причины и без ничего очевидного в журналах.
Я искал в Google все, что мог, и не могу найти никого, кто сталкивался с этой проблемой.
База данных, о которой идет речь, содержит около 30 таблиц, одна из которых содержит большинство отчетов. Я могу нормально восстановить все метаданные таблиц, и все, кроме большой таблицы (используя флаг exclude-table). Но когда я пытаюсь восстановить большую таблицу, я получаю эту проблему, когда ndb_restore просто останавливается.
Я использую MySQL кластер 5.6.23 с ndb-7.4.5. Кластер состоит из 6 узлов данных (работает ndbmtd), 1 узла управления и 3 узлов API (каждый с 3 соединениями, поэтому логически 9 узлов API на 3 серверах)
Все используемые таблицы являются таблицами дисковых данных, табличное пространство достаточно велико, чтобы вместить весь набор данных, и система имеет достаточно ОЗУ для хранения индексов и индексированных столбцов.
Любая помощь с этим будет принята с благодарностью (если вам нужна дополнительная информация, пожалуйста, спросите!)
1 ответ
Я думаю, что я нашел решение.
Я запускаю ndb_restore через скрипт, который я выполняю через SSH-соединение, так как в настоящее время у меня нет физического доступа к серверам. Также, когда сеанс SSH умирает, ndb_restore получил SIGHUP. Я считаю, что именно это и стало причиной остановки процесса без какого-либо уведомления или регистрации сообщений.
С тех пор я обнаружил, что могу предотвратить это, запустив сценарий (ctrl+z; bg):
disown [job id]
Подробнее об этом смотрите: