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