1️⃣🔤 + 🔤🔤🔤 Когда реструктуризация 2.0 или перенос базы между СУБД через ibcmd replicate может завершиться с ошибкой при том что всё работает штатно?

Представьте, запустили вы реструктуризацию своей любимой 1С-ки через оптимизированный механизм реструктуризации 2.0 , всё идёт хорошо и вдруг получаем ошибку обрыва соединения, реструктуризация прерывается и достаточно сложно вернуть базу в начальное состояние без восстановления на резервную копию ДО реструктуризации (а резервные копии же у вас есть всегда!?).

Такая же ситуация может произойти и когда идёт репликация базы между СУБД с помощью утилиты ibcmd replicate...

Причём ошибка может звучать либо очень странно - что-то там про таймаут либо в случае ibcmd будет просто сообщение что репликация завершилась с ошибкой.

❗️Главная особенность именно этой ошибки, что она происходит по истечении более чем ДВУХ часов!

Что за волшебные 2 часа и что вообще происходит?

В операционных системах Windows и почти во всех Linux есть ограничение на ожидание последнего пакета, отправленного по сети.
По прошествии этого времени соединение помечается как требующее проверки, затем несколько раз проверяется и если проверки закончились неудачно. то оно разрывается.

А с чего это вдруг система решила что прошло уже 2 часа?
Это будет в том случае, если мы натолкнулись на создание огромного индекса .т.е. команду CREATE INDEX.
Эта команда вернёт обратно утилите своё состояние только по завершению создания индекса, т.е. это одна транзакция., а не несколько (единиц, десятков, сотен, тысяч и т.д.) как в случае когда мы заполняем таблицы данным при реструктуризации или репликации.

Повлиять на скорость создания индекса достаточно сложно, хотя можно, и как это сделать в PostgreSQL расскажу в следующий раз.
А вот повлиять на поведение системы, чтобы она не прерывала такое соединение можно достаточно просто.

Для Linux:
▫️sysctl net.ipv4.tcp_keepalive_time узнаём какой сейчас стоит таймаут, обычно ответ будет 7200
▫️Если он меньше чем нам нужно, то устанавливаем новое значение в секундах, которое заведомо больше нашего времени создания индекса sysctl -w net.ipv4.tcp_keepalive_time=14400 в секундах!
▫️Если мы хотим установить этот параметр так чтобы он подтянулся и после перезагрузки, то нужно в файле /etc/sysctl.conf добавить строчку: net.ipv4.tcp_keepalive_time = 14400

Для Windows:
▫️В разделе реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

создаём параметр DWORD с именем KeepAliveTime и значением 14400000 в миллисекундах!
▫️Перезагружаем систему

Какое время необходимо вам для создания индекса конечно нужно смотреть в логах СУБД заранее настроив их на сбор длительных запросов.