Репликация в DIRECTUM с OKtopus – это просто! Часть 3: день администратора DIRECTUM с OKtopus.

В статьях 1 и 2  я рассказывала о нашей новой разработке – программном комплексе «OKtopus», который позволяет значительно упростить мониторинг за процессами репликации между серверами DIRECTUM. В первой статье были описаны общие сведения, мы описали архитектуру и идею «OKtopus». Во второй статье было рассказано про процесс установки «OKtopus». Конечно, хочется понимать, а для чего оно все? Что это даст и как это поможет мониторить репликацию? Предлагаем вашему вниманию описание функциональных возможностей на примере реальных ситуаций. Это так называемый формат case study, на наш взгляд именно этот формат позволит просто, доступно и интересно рассказать то, что обычно пишется в занудных инструкциях. Итак, опишем парочку типичных ситуаций и посмотрим, чем может помочь «OKtopus» в этих ситуациях.

Ситуация 1.

Администратор первый день на новом месте работы. Понятное дело, он не знает еще, как устроена сеть в организации, как там должна происходить репликация. Вникать самому долго, что где искать – непонятно. И тут ему говорят посмотреть все это в  «OKtopus»…

Запускает «OKtopus»… открывается окно программы и сразу картина проясняется.

Сразу видно, в сети 2 сервера репликации, оба работают. Надо посмотреть более подробно про сервер? Мышкой его выделяй и отобразятся свойства сбоку – тут видно основные характеристики, что за сервер, на какой машине он развернут… Уже нет проблем с выяснением того, где какой из серверов DIRECTUM  установлен. А еще при клике мышкой на сервер загружаются логи репликации с этого сервера на отдельную вкладку. Удобно! Не надо лезть в SQL Management Studio и искать там последние сеансы.

Конечно, надо потыкать по вкладкам, куда ж без этого =)

Идем на вкладку «Главная».

Опа! Запросы можно отправлять, трех видов. Надо только сервер указать, запрос еще написать. Попробуем… Укажем сервер, выберем тип запроса и сам запрос, нажимаем кнопку «Отправить»…

На вкладке «Ответ» появился ответ от указанного сервера. Ну что же, тоже удобно, можно лишний раз не подключаться к нему.

Ладно, это понятно.  А в «Настройках» что?

А тут куча вкладок и первая из них «Настройки подключения». Подключения к базам данных - это понятно. Видно, что используется 2 подключения минимум – к базе DIRECTUM главного сервера и к базе OKtopus. А вот еще ниже есть дополнительные настройки:

• «Опрашивать сеть каждые N сек» - эта настройка задает периодичность опроса серверов репликации. Это как ping – проверка, работает ли сервер, в сети ли он. Если сервер не ответил на запрос, он будет отмечен на схеме на вкладке «Визуализация».
• «Таймаут подключения» - сколько ждать ответа от сервера. Не бесконечно же, поэтому ограничиваем.
• «Количество попыток передачи данных» - сколько раз пытаться передать пакеты репликации, если не получается передать сразу.
• «Максимальный размер передаваемого блока данных» - если пакет репликации больше, чем указано в этой настройке, то «OKtopus» поделит его на куски указанного размера (тут в примере 512 байт) и будет передавать этот пакет по кускам. Нужно это для экономии трафика при частых обрывах соединения. Так хоть можно докачать не до конца переданный пакет репликации, а не запрашивать его закачку заново. Хотя, если за указанное количество раз не удалось доставить кусок пакета репликации, попытки докачки пакета  заканчиваются.

Все эти параметры можно изменить под потребности организации. Например, если есть нормальный канал связи между серверами, можно увеличить размер передаваемого блока данных до размера среднестатистического пакета репликации. «OKtopus» тогда будет передавать его целиком.

Идем дальше: вкладка «Сервера репликации».

Тут снова те же сервера репликации, только в виде таблицы. Кнопки справа позволяют отредактировать данные о сервере, добавить новый сервер, удалить сервер… Кнопка «Собрать данные» опрашивает каждый сервер в этой таблице и получает от них такие данные, как например, сведения об операционной системе, оперативной памяти и процессоре.

Что еще может заинтересовать новичка? Ну,  разве что вкладка «Расписание».

В поле «Расписание» задается порядок репликации для серверов. Сервер в данном случае только один, потому что в сети всего один вторичный сервер. Главные сервера не попадают в этот список, потому что они не начинают репликацию. Вот если бы в сети было несколько вторичных серверов, тогда с помощью этого списка можно было задавать приоритет, на каком сервере раньше выполнить репликацию, на каком позже.

Галочка «Включить репликацию» - показывает, включена ли репликация. Отключить иногда бывает надо, например, на время ввода нового сервера репликации, чтобы он мог без проблем обменяться полными данными. Да и так, мало ли зачем.

Там же можно задать время репликации: со скольки и до скольки. Тоже очень удобно, ведь репликация ночью бессмысленна в большинстве случаев. И запускать репликацию можно с заданной периодичностью. А вот если  «OKtopus» обнаружит, что репликация не выполнялась указанное на этой вкладке время, то будет сигнализировать об этом, вот так:

Ну вот, наглядно и доступно ввели в курс дела нового сотрудника.

Ситуация 2.

Предположим, случилась ошибка репликации. Чем в этой ситуации может помочь «OKtopus»?

Допустим, открывает администратор «OKtopus», а там…

Вот тебе на! Давайте разбираться. Выбираем самый последний сеанс репликации мышкой (в таблице он самый первый), в правой стороне в протоколах приема и передачи отобразятся записи, связанные с выбранным сеансом репликации. Поскольку здесь в примере передавалась только одна запись, то в протоколе приема только одна строка.  Надо посмотреть что за ошибка. Для этого смотрим повнимательнее строку в протоколе приема:

Ошибка «Отсутствует запись для изменения»!

По сути, ошибка решается SQL-запросом, который исправляет действие «Изменение» на «Добавление». А теперь представим, что таких однотипных ошибок куча и для каждой выполнять отдельный запрос с разными параметрами как-то не хочется. Да и самим ошибиться несложно при такой рутинной работе. Ну ладно, допустим один день поисправляли ошибки, неделю все работает, а потом снова сидеть исправлять? Нет… Администратор делает умнее: переходит на вкладку «Решение конфликтов репликаци».

И добавляет запись в справочник решения конфликтов. В открывшемся окне указывает, где искать ошибку, где ее исправлять, какую ошибку искать и… SQL-запрос, который исправляет такую ошибку. После сохранения этой записи следующая репликация будет проходить немного иначе: при обнаружении такой ошибки на указанном сервере будет выполнен SQL-запрос на исправление. С помощью этого запроса корректируется журнал действий. Эти корректировки учитываются при следующем сеансе репликации и ошибка исчезает, репликация проходит нормально.

Настроив решение конфликта один раз, не придется возвращаться к нему в дальнейшем. Таким образом, ошибок будет меньше, работа системы будет стабильнее, а администратор будет спокойнее =)