УСЛОВИЯ ОБРАБОТКИ СБОЕВ

Когда OE Replication работает, активность базы данных находится в нормальном состоянии. Если же OE Replication сталкивается со сбойной ситуацией, выполняется обработка этой ситуации. При этом восстановление основывается на различных характеристиках сбоя, которые разделены на две категории:

• Сбой базы данных
• Потеря связи

Примечание: остановка source или target базы с помощью команды PROSHUT без применения параметра <–F> (force) не считается сбойной ситуацией и не приводит к запуску процесса восстановления. Остановка сервера репликации командой DSRUTIL db-name –C terminate Server или остановка агента с помощью команды DSRUTIL db-name –C terminate Agent не классифицируется как сбой.

Сбой базы данных означает что, в случае повреждения source или target базы OE Replication немедленно реагирует на это событие. Если повреждена target-база, сбой происходит в работе агента репликации. В этом случае сервер репликации выполнит процесс failure recovery, поскольку он потерял соединение с агентом. Если повреждена source-база, то нарушается работа сервера репликации. В этом случае агент репликации переходит к выполнению failure processing, например, при потере связи с сервером.

Потеря связи означает что, сервер репликации потерял контакт со своими агентами. Это может произойти по следующим причинам:

• Аварийная остановка сервера репликации
• Системный сбой машины, на которой запущен сервер репликации
• Разрыв TCP/IP-соединения между сервером и агентом репликации

После потери соединения source-база переходит в режим failure recovery, а target-база в режим transition.

Есть вероятность того, что потеря TCP/IP-соединения между сервером и агентом репликации пройдет незаметно. Например, в больших сетевых комплексах с большим количеством различного сетевого оборудования один из сегментов сети может выйти из строя, вызвав этим разрыв связи между хост-машиной агента и хост-машиной сервера. Но, тем не менее, TCP/IP по-прежнему остается работать в другом сегменте сети, и сервер или агент могут не подозревать о разрыве связи. Проверка наличия связи TCP/IP между агентом и сервером выполняется через пингование (от англ. ping). Для включения этой возможности необходимо использовать параметр Repl-Keep-Alive в файле свойств агента репликации. Пингование будет выполняться каждые тридцать секунд. Этот параметр позволяет задать время ожидания ответа в секундах. Если ответа за это время нет (по умолчанию 300 сек.), то считается, что возникла проблема со связью и начинается процесс обработки сбойной ситуации failure recovery.

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

1. Сервер репликации обнаруживает, что произошел сбой связи с агентом.

2. В течение определенного времени сервер пытается установить соединение с агентом репликации. При этом активность source-базы поддерживается в нормальном режиме, если не используется синхронный метод репликации, или пока схема базы может быть изменена процессами.

3. Если серверу удалось соединиться с агентом, он начинает передавать AI-блоки. Когда останется примерно 10 AI-блоков, сервер репликации приостановит активность базы данных и завершит процесс синхронизации. Во время выполнения синхронизации невозможно обновление схемы. Если в момент выполнения failure recovery схема будет изменяться, то source-база будет заблокирована до тех пор, пока процесс не будет завершен. Активность source-базы не может продолжаться без агента репликации, работающего в синхронном режиме.

4. Когда процесс синхронизации будет завершен, сервер репликации перейдет в нормальный режим обработки AI-блоков и работа базы и репликация продолжатся в нормальном режиме.

Если серверу репликации не удалось подключиться ко всем агентам репликации или к критичному агенту (если такой имеется) в период, определенный параметром connect-timeout, то сервер репликации будет остановлен и работа source-базы продолжится в нормальном режиме. Другими словами, если нет критичного агента, сервер должен иметь возможность подключиться ко всем некритичным агентам, либо его работа будет завершена. Если один агент является критичным, то сервер продолжит работу при возможности подключения только к нему. При этом следует помнить, должно быть достаточно свободного пространства в AI-экстентах, что бы вместить все изменения за время простоя сервера репликации, если активность source-базы продолжается.

Есть вероятность, что во время выполнения процесса синхронизации работа сервера репликации будет отставать от работы RDBMS, поэтому на это время source и target базы могут отставать по времени.

Когда агент репликации теряет соединение с сервером репликации, он переходит в состояние pre-transition. В таком состоянии, если настроен автоматический переход, агент для восстановления соединения «слушает» запросы от сервера репликации в течение времени, указанного параметром transition-timeout. При этом происходит следующее:

1. Когда связь теряется впервые, агент переходит в состояние pre-transition, в котором «слушает» запросы сервера репликации.

2. Если связь не установлена, и агент настроен на автоматический переход, target-база переходит в режим работы нормальной OpenEdge базы. Это означает, что все стандартные возможности работы с базой данных восстановлены.

3. Если настроен ручной переход, агент репликации продолжает ожидание соединения до тех пор, пока администратор вручную не выполнит transition. Пока администратор этого не сделает с помощью утилиты DSRUTIL база будет находиться в неопределенном состоянии.