"Маленькие" проблемы больших систем или когда бэкап ломается

Рассмотрим процесс повышения надежности бэкапа на больших системах. Сам процесс бэкапа может быть длительным. И неприятно когда этот достаточно долгий процесс может завершится с ошибками. Что значит отсутсвие бэкапа или старый бэкап думаю понятно. Причины по которым бэкап может не пройти до конца могут быть различными, и в таком случае надо предпринять действия для того чтобы спасти хотя бы его часть. Здесь и далее речь идет про бэкап выполненный с помощью onbar, и дальше вы поймете почему. Рассмотрим бэкап запущенный на выполнение с помощью простой команды "onbar -b -L 0".




Такой бэкап выполняется как некий единый процесс и в случае если произойдет ошибка и процесс завершится (например прервется соединение с storage manager), то что onbar успел сохранить в TSM будет потеряно, информация об уже сохраненных объектах будет недоступна информиксу, в файле ixbar не будет записано никаких сведений об сохраненных объектах. Как быть в таком случае? На помощь приходит т.н. раздельный бэкап по dbspace. При запуске в onbar указываются dbspace которые должны быть архивированы. Т.е. скажем если в системе есть несколько dbspace c именами rootdbs, phylog, data, test, bigdata то можно процесс бэкапа запустить последовательно:



Т.о. небольшие dbspace rootdbs, phylog, data, test будут архивированы быстро и вероятность отказа при малом промежутке времени достаточно мала, затем будет запущена архивация большого dbspace bigdata, и даже если во время этого процесса произойдет сбой, информация о предыдущих dbspace не будет потеряна. Поэтому придется заново запустить бэкап только для dbspace bigdata.
Восстановление из такого бэкапа выполняется как обычно. Такой бэкап также можно использовать для физического восстановления при инициализации репликации HADR.
Единственный минус этого способа - надо быть внимательным при перечислении всех имеющихся в системе dbspace.

Connection Manager

Клиент информикса версия 3.5xC1 вышел (еще в мае). В клиенте появился новый компонент: Менеджер соединений (Connection Manager). Он позволяет автоматически перенаправлять соединения клиентов в зависимости от нагрузки на серверах к менеее нагруженному серверу в кластере HDR. Кроме того можно реализовать автоматический failover (перенаправление на работающий сервер) в случае сбоя одного из серверов HDR.
IBM - IBM Informix Client SDK v3.50.xC1: Release notes, documentation notes, and machine notes

HDR: как secondary сделать на время доступным для обновлений

Бизнес требует от ИТ инфраструктуры постоянной доступности ресурсов и данных. В то же время некоторые задачи (например обновление ПО, модернизация оборудования) требуют перерывов в работе ИТ-сервисов. И здесь встает задача минимальной задержки в обеспечении работы ИТ. HDR обеспечивает высокую надежность и доступность данных, даже когда primary сервер HDR недоступен в течение некоторого времени. В этом случае обновления данных принимает на себя secondary сервер, который на время недоступности primary делается стандартным. После запуска primary репликация HDR восстанавливается в прежнем виде. Далее по шагам объясню как это сделать.

1. Сервер primary выключаем (или он недоступен после устранимого сбоя оборудования)
2. secondary переводим в режим standard:

onmode -d standard

3. клиентские приложения теперь могут работать с бывшим secondary в режиме обновления данных
4. Через некоторое время запускаем primary: переводим стандартный (бывший secondary) сервер в режим quiescent, делаем его вновь secondary:

onmode -s (или -u если требуется немедленно отключить сессии)
onmode -d secondary prm_srv_name

5. Запускаем primary, который накатывает на себя все обновления сделанные на secondary который был в режиме standard

после этого репликация снова восстанавливается.

Данная процедура переключения secondary > standard > secondary при отключенном primary является стандартной и описана в документации.