Я работал над переносом нашей текущей базы данных с одним экземпляром в новую кластерную базу данных с кластером 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 серверах)
Все задействованные таблицы представляют собой таблицы данных на диске, табличное пространство достаточно велико, чтобы содержать весь набор данных, а в системе достаточно оперативной памяти для хранения индексов и индексированных столбцов.
Любая помощь в этом будет принята с благодарностью (если вам нужна дополнительная информация, спросите!)
Я думаю, что нашел решение.
Я запускал ndb_restore через скрипт, который выполнял через SSH-соединение, поскольку в настоящее время у меня нет физического доступа к серверам. Таким образом, когда сеанс SSH умирает, ndb_restore получил SIGHUP. Я считаю, что именно это привело к остановке процесса без каких-либо уведомлений или сообщений журнала.
С тех пор я обнаружил, что могу предотвратить это, если скрипт будет запущен (ctrl + z; bg), запустив:
disown [job id]
Подробнее об этом см .: