|
Задавайте вопросы, мы ответим
Вы не зашли.
Приветствую.
Столкнулись с проблемой, когда при удалении данных файл ibdata1 не уменьшается, а место нужно высвободить (порядка 100Гб). Если известны способы его уменьшения без переноса данных - буду благодарен за любую информацию. Percona XtraDB Cluster 5.6, innodb_file_per_table = 0.
Пытались схитрить путём добавления новой ноды в кластер, думали сольются только данные, а слился весь тейблспейс, фокус не удался 
Остаётся вариант с дампом данных, но там более 200Гб на достаточно активном b2b сервисе, каждая минута простоя на счету, такую роскошь не можем себе позволить.
Вижу два варианта:
1. Модернизация оборудования путём установки более ёмких жёстких дисков.
2. Пересоздать кластер с минимальным временем простоя.
Первый случай, естественно, не дешёвый (серверов несколько, везде по 2 диска).
Для второго случая прикинули следующую процедурку: создаём новый кластер, заливаем туда структуру всех таблиц и минимальный набор данных, отключаем сервис, снимаем показания следующего автоинкремента по всем таблицам и обновляем их в новом кластере, переключаем сервис на работу с новым кластером. В итоге, старые пользовательские данные недоступны, но новые пишутся и автоинкременты больше, чем в старой базе. Затем делаем дамп данных старого кластера и заливаем его в новый. Таким образом, простой должен занять пару минут, пока переносятся данные по автоинкрементам, которыми будет заниматься конечно же заранее написанный скрипт.
Какие подводные камни могут возникнуть в описанном выше способе? Сейчас под кластер отведено 4 сервера, в старом кластере оставим 2 ноды, новый создадим на освободившихся двух, вроде бы всё сходится, но может всё-таки где-то суслик притаился 
Неактивен
Без переливки текстом, к сожалению, способа хорошего нету. Но есть способ без простоя данных — вы можете сделать полноценную реплику (через текст), а потом из этих данных сделать кластер. Т.е. та же идея, что у Вас, только полноценный набор данных. Ну и потом досинкать уже xtrabackup после переключения.
Единственное, что смущает, — у Вас четное количество нод в кластере, это потенциально плохо. Нужно или 3, или 5 (5 может быть неполноценным арбитром: http://galeracluster.com/documentation- … rator.html).
Неактивен
Чётное количество у нас стало когда добавили ещё ноду, в надежде что сольются реальные данные. А так-то обычно их 3. Хотя вообще интересно, почему лучше не чётное?
Не совсем понял как именно можно перелить данные без простоя. Стандартную реплику в работающем кластере мы ведь не можем настроить. Можно на паре пальцев прикинуть что куда?
Неактивен
Про нечетное — это требование для того, чтобы не было split brain. Если совсем на пальцах, то представьте, что у вас есть кластер из 4 компьютеров, потом между ними рвется сеть так, что два компьютера видят друг друга, и еще два видят друг друга, но пары друг друга не видят. Тогда они считают, что кластер доступен, просто «вот те два компьютера упали», и принимают данные, в результате получится, что на разных компьютерах разные наборы данных. В случае с нечетным количеством всегда можно отличить ситуации «те компьютеры упали» и «я потерял связность до других компьютеров, поэтому на всякий случай не буду работать».
Перелить без простоя — делаете mysqldump + restore на четвертом компьютере и подцепить обычной схемой репликации. Когда реплика догонит кластер, сказать, что теперь она мастер, и начать работать с ней как с кластером, а старые компьютеры после этого перелить через xtrabackup.
Неактивен
