Миграция старый сервер = новый сервер

[ToxaRat]

Задача
нужно перекинуть данные со старого сервера на новый - модификация и улучшение железа
оба сервера имеют одну и ту же ID

как правильно сделать переезд при одновременно работающих двоих

Ранее я просто копировал все данные, на файловом уровне а потом просто поднимал новый с IP как у старого

Теперь стало интересно как это сделать не на файловом уровне

Имеем кучу баз, ДАОС и т.д.

Обьединить их в кластер и сделать синхронный кластер не получится, но нужно что-то вроде такого, чтобы они сами с синхронились и позволили всё автоматически разрулить

Идеи?

 

[savl]

а эти сервера одновременно в сети? и нет конфликтов?

можно попробовать закрыть доступ к новому и с клиента пустить реплику, по IP.
Да трафик через клиента пойдет, но это может сработать. Этакий треугольник: Сервер А, Сервера А' и Клиент B.
и все же с подменой IP проще будет, раз ID одна.

 

[Pernat1y]

1. Собрать кластер с репликацией из 2х серверов. Иначе онлайн перенести БД не получится.
2. Поднять балансер, который после переноса данных на новый сервер просто переключит клиента туда.

 

[lmike]

взять ZFS, дропнуть соединения на первом (либо стопнуть домину, что надежней, в смысле агентов), снимок, отправить снимок на вторую ноду (синхронизация займет время от размера стораджа, потому первый надо будет держать доступным, время на снимок мало), остановить первый, разностный снимок на вторую ноду (будет быстро), запустить вторую ноду...
ах да - это не для винды
в схеме будет перерыв по доступу, зато синхронность гарантирована, как и имя сервера сохранится
это не файловый уровень, а блочный, работает достаточно быстро
отправка как по сети так и локально, с тз ZFS разницы не будет
пример для локального разностного:

 zfs send -I rpool/vm-201-disk-0@2020-08-22_00:28 rpool/vm-201-disk-0@2020-09-18_21:37 | pv | zfs recv tank/vm-201-disk-0

между пайпами вставляем ssh и получаем сеть
от оракля примеры

Ссылка скрыта от гостей

это работает для ZOL (ZFS on Linux) и proxmox в частности (где ещё есть и HA с общим стораджем)

 

[lmike]

1. Собрать кластер с репликацией из 2х серверов. Иначе онлайн перенести БД не получится.
2. Поднять балансер, который после переноса данных на новый сервер просто переключит клиента туда.

у ХСЛ есть туториалы как держать кластер синхронным по базам (сами будут создаваться и поддерживать рабочее состояние)
балансер для клиента - это делается самим клиентом (если про нотусню)

 

[ToxaRat]

у ХСЛ есть туториалы как держать кластер синхронным по базам

да, но там название серверов всё же разное

 

[savl]

Был бы контейнер было бы проще, там считай только бины да настройки. Но я не эксперт.
А так, либо подмена, либо треугольник, только важно чтобы трейс клиента был по ip, ну и реплики гнать именно по ip.
тот же daos не обязательно переносить на ФС-уровне, просто второй сервак во время реплики будет его создавать.
Важен еще момент с шифрованием NLO, но если имя одно и id одна, то теоретически можно перенести и на ФС-уровне.

Хотя все же теоретически... оба сервера онлайн.. а работа сразу на двоих будет идти?
я к тому, что можно поднять второй сервер с минимальными задачами: выключить все что только можно.
потом на уровне ФС перенести данные, которые нужны.
Domino штука забавная, она позволяет на лету добавлять базы в Data, можно даже не в Data + Folder/db Link, будут ли они сразу доступны - не скажу, но скорее всего будет некий лаг.
отдельный момент с логами транзакций.. как они себя поведут.

 

[rinsk]

да, но там название серверов всё же разное

Ну после репликации - поменять id )

 

[lmike]

Ну после репликации - поменять id )

тоже вариант
но палюбому даунтайм

 

[rinsk]

тоже вариант
но палюбому даунтайм

Всегда без даунтайма обходится с кластером, забывая навсегда имя сервера хотя не - помню была серия из Basra, Mosul, Falludgi...
Не понятна сама привязка к имени сервера, которая ведёт к проблемам переноса...

 

[zakrush]

Мы когда то держали резервный сервер на случай отказа основного (горячий резерв). Так реализовано было следующим образом:
1. Базы на реплике.
2. Остальные необходимые данные на rsync.

Второй резервный сервер естественно предварительно настроен как надо.
На основном сервере стопаришь коннекты к базе, ждешь пока слейв догонит мастера, переключаешь их местами.
Далее весь трафик с основного сервера перегоняешь на новый(например на уровне nginx). (Это если ИП поменялся и DNS пока еще не обновились). Потом, когда все норм и страбилизировалось, убираешь старый сервер.
Схема проста до не возможности. И даунтайм минимальный.
Плюс схемы, в том, что если пошло не так, можно быстро откатиться.
Из советов: когда будешь делать трюки в конфигах(например в nginx) бэкапься. Самое простое гитом.

 

[lmike]

Мы когда то держали резервный сервер на случай отказа основного (горячий резерв). Так реализовано было следующим образом:
1. Базы на реплике.
2. Остальные необходимые данные на rsync.

Второй резервный сервер естественно предварительно настроен как надо.
На основном сервере стопаришь коннекты к базе, ждешь пока слейв догонит мастера, переключаешь их местами.
Далее весь трафик с основного сервера перегоняешь на новый(например на уровне nginx). (Это если ИП поменялся и DNS пока еще не обновились). Потом, когда все норм и страбилизировалось, убираешь старый сервер.
Схема проста до не возможности. И даунтайм минимальный.
Плюс схемы, в том, что если пошло не так, можно быстро откатиться.
Из советов: когда будешь делать трюки в конфигах(например в nginx) бэкапься. Самое простое гитом.

ну это есть прокмокс HA называется, ток полку надо (общий сторадж), или реплики ФС (но там заморочится с остановкой домины надо)