Informix Logo


В Informix репликация есть! 
 
REPLAY

 

Ранее среди специалистов в области СУБД можно было встретить мнение, что  в Informix репликации нет . Семинар Представительства Informix, посвященный встроенным в СУБД этой компании средствам тиражирования, позволяет убедиться, что это мнение, по крайней мере, устарело. 

 

Какие средства тиражирования предлагает СУБД Informix?

            Эти средства можно разделить на четыре составляющих. 
            Первая из них   это так называемое  горячее резервирование данных  (High Availability Data Replication), предоставляемое вместе с нашими серверами СУБД уже давно   с версии Online 6.0. 
            Вторая, более новая технология тиражирования, называется  тиражирование для предприятий  (Enterprise Replication). Она включает в себя весь спектр современных требований к тиражированию и позволяет создавать сложные модели распространения измененных данных. 
             Тиражирование для рабочих групп  (Workgroup Replication), третья из упомянутых четырех составляющих, является упрощенной версией  тиражирования для предприятий . В Workgroup Replication не включены такие возможности, как  всеобщее обновление  и автоматическое разрешение конфликтов при обновлениях (см. ниже). 
            Последняя составляющая тиражирования    гетерогенное тиражирование  (Heterogeneous Replication)   представляет собой отдельный программный продукт   Praxis Omnireplication. Он осуществляет двухстороннее тиражирование данных в СУБД других производителей: Oracle, Sybase, DB2 и др. 

Что собой представляет  горячее резервирование  и где оно применяется?

            Эта технология тиражирования состоит в том, что две СУБД, расположенные на разных компьютерах, полностью синхронизируют свое содержимое. При этом один из серверов позволяет пользователям только читать данные; он называется ведомым, а второй   соответственно, ведущим. Горячее резервирование предъявляет к распределенной системе достаточно жесткие требования: оба сервера должны работать под управлением одной и той же операционной системы и иметь одинаковые настройки, определяющие  жизнеспособность  серверов. Например, у них должны полностью совпадать имена и размеры сегментов БД (dbspace); они должны также иметь одинаковые журнальные файлы (log). В то же время параметры производительности, например, настройки блокировок и размер буфера, у них могут быть разными. Преимуществом этого тиражирования является то, что ведомый сервер имеет возможность в любой момент стать ведущим, например, в случае сбоя на втором сервере. 

Рис. 1 Разгрузка
Разгрузка

            Горячее резервирование может применяться в простейшей модели тиражирования, называемой  разгрузочной  (capacity relief, рис. 1). На основе этой модели можно совместить системы оперативной обработки транзакций (OLTP) и системы поддержки принятия решений (DSS). В таких системах количество пользователей постоянно растет, а поток транзакций является очень интенсивным. Чтобы увеличить производительность системы, не переходя на более мощный сервер, можно добавить к существующему серверу еще один, настроить его на работу в режиме  горячего резервирования  и направлять к нему запросы чтения данных. Тогда нагрузка на первый сервер снизится, позволяя ему более интенсивно выполнять транзакции обновления данных. 

Какие модели распространения изменений позволяют реализовать тиражирование для предприятий?

Рис. 2 Консолидация
Консолидация

            Сначала рассмотрим общие схемы тиражирования. Кроме упомянутой  разгрузки , это схемы  консолидации  (consolidation, рис. 2),  распространения  (dissemination, рис. 3) и  центр обращений  (call center, рис. 4). Они применяются для объединения в одной БД данных, накопленных многочисленными филиалами, для передачи данных только для чтения и одновременной модификации одной и той же БД в разных узлах сети. Существует также схема  разделения рабочей нагрузки  (workload partitioning, рис. 5), при которой записи одной таблицы с разными диапазонами значений первичного ключа обновляются разными узлами сети. С помощью этих схем можно реализовать тиражирование любой сложности. 
 

Рис. 3 Распространение
Распространение

 

Рис. 4 Центр обращений
Центр

 

 

Рис. 5 Разделение рабочей нагрузки
Разделение

            В Informix применяется два подхода к распространению изменений в перечисленных базовых схемах:  публикация   подписка  (publish   subscribe) и  всеобщее обновление  (update anywhere), которые позволяют иметь либо только одного  владельца  данных, либо нескольких, соответственно. 
            По способу реализации тиражирование может быть либо триггерным (trigger-based), либо журнальным (log-based). Первый способ означает зависимость распространения изменений от самого события обновления и требует дополнительных ресурсов, поскольку триггеры, включаемые по определенным событиям обновления, замедляют работу транзакций на узле, вносящем изменения. Кроме того, этот подход заставляет включать принятую схему тиражирования в хранимый в БД код, что усложняет разработку. В Informix применяется  журнальное  распространение изменений, т.е. распространение, основанное на журналах транзакций. В них все произведенные в БД изменения, подлежащие распространению, маркируются. Затем в рамках нормального процесса регистрации через заданные промежутки времени журналы просматриваются, и все внесенные изменения группируются по транзакциям: завершенные транзакции помещаются в очередь на отсылку, а прерванные отбрасываются. Процесс тиражирования данных может происходить как непрерывно, по мере завершения транзакций, так и в заранее указанные моменты времени, что определяется на этапе описания реплицируемого набора данных. Журнальный подход позволяет также тиражировать не только записи (row-by-row replication), но и транзакции, благодаря чему достигается лучший контроль целостности данных. 
            В Enterprise Replication все субъекты тиражирования должны иметь непосредственную связь друг с другом. В ряде случаев это приводит к дополнительным накладным расходам в рамках всей распределенной системы. В версии Online Dynamic Server 7.3 будет введено так называемое иерархическое тиражирование, одним из применений которого является  каскадирование  изменений. 

Как обнаруживаются и разрешаются конфликты, возникающие при условии, если несколько владельцев обновляют на разных узлах одни и те же данные?

            В серверы Informix встроена логика, позволяющая разрешать конфликты автоматически по алгоритмам  временной метки  (time stamp), т.е. времени, которым в журнале транзакций помечено выполненное изменение, а также  с помощью пользовательской хранимой процедуры, которая автоматически вызывается при возникновении конфликта. Различают первичное и вторичное правила. В случае использования алгоритма разрешения конфликтов на основе  временной метки  более приоритетными окажутся те изменения, которые сделаны позже, независимо от того, когда они попали на узел-репликант (в случае потранзакционного тиражирования временем совершения транзакции считается время последней модификации данных в рамках этой транзакции). Вторичные правила определяются хранимыми процедурами, позволяющими воплотить собственную технологию разрешения конфликтов. Это необходимо, например, если у конфликтующих транзакций временные метки совпадают. Конфликты также могут быть просто проигнорированы, при этом  актуальными  окажутся те изменения, которые попали на узел-репликант позже. 

Рис. 6 Преобразование UPDATE в INSERT
UPDATE-INSERT

            В средах update-anywhere необходимо всегда помнить, что во время разрешения конфликтов операции UPDATE и INSERT могут трансформироваться одна в другую. Рассмотрим пример (рис. 6), в котором есть три  всегда обновляемых  сервера. На одном из них операцией INSERT добавлена запись, которая затем была реплицирована на два остальных. На втором узле эта запись удаляется, а на третьем одновременно со вторым обновляется. Тогда в зависимости от логики, определенной администратором, команда UPDATE может быть либо отброшена, либо преобразована в команду INSERT. Аналогично, в других ситуациях команда INSERT может быть преобразована в команду UPDATE. Этот пример также показывает, что репликация может привести к неожиданному срабатыванию триггеров, что заставляет тщательно подходить к разработке. 
            Есть еще один пример, когда репликация может привести к неожиданным последствиям,   репликация полей типа SERIAL. Дело в том, что счетчики SERIAL ведутся независимо на каждом из репликантов, поэтому есть вероятность, что два узла попытаются добавить  разные  записи с одинаковым значением ключа и одна из таких записей будет потеряна при разрешении конфликта. Возможный выход из такой ситуации   различные начальные значения SERIAL на каждом из узлов, а если этого недостаточно и отведенные диапазоны начинают все же перекрываться, можно строить первичный ключ по двум полям   SERIAL и, например, символьное поле, куда по умолчанию помещается имя узла. 

Как происходит распространение изменений на разные узлы?

            Начнем с того, что средства тиражирования в семействе серверов Informix представляют собой не отдельное приложение, а встроены в ядро СУБД. Это дает возможность воспользоваться преимуществами DSA (Dynamic Scalable Arсhitecture) и распараллеливать и сам процесс тиражирования данных. Кроме этого, отсутствуют накладные расходы на синхронизацию между отдельными процессами (сервер данных   сервер репликации) и нет необходимости преобразовывать данные между несколькими коммуникационными протоколами, что позволяет повысить производительность. 
            Тиражирование в Informix имеет так называемую  многонитевую  структуру, в которой  нить  соответствует потоку транзакций между двумя соседними узлами. Выделение транзакций из журнала, их распространение и внесение в целевую БД осуществляется параллельными процессами, что повышает производительность. Реплицируемые данные помещаются в  устойчивую очередь  (stable queue), в которой, в случае сбоев в сети, они остаются до тех пор, пока работоспособность сети не будет восстановлена. 
            Данные, подлежащие репликации еще до рассылки узлам-репликантам, логически сжимаются, например: незавершенные транзакции и транзакции, для которых был выполнен ROLLBACK, не реплицируются, а если в пределах транзакции одни и те же данные изменялись несколько раз, то реплицироваться будет только окончательный вариант данных.  Это обстоятельство, хотя и существенно снижает сетевой трафик, требует некоторой осторожности в использовании триггеров на реплицируемых таблицах. Ведь если в одной и той же транзакции над одними и теми же данными была проведена операция INSERT, а затем 3 раза UPDATE, то в то время как на ведущем сервере сработают 1 раз INSERT-триггеры и 3 раза UPDATE-триггеры, на ведомом сработают только INSERT-триггеры, поскольку будет передан лишь  результирующий  INSERT со значениями последней операции UPDATE. Да и то лишь в том случае, если логика разрешения конфликтов на узле-репликанте не преобразует его в UPDATE. 

Можно ли тиражировать подмножества таблиц?

            Конечно. Может тиражироваться не только таблица как единый набор данных, являющийся результатом выражения типа select * from  table , а и подмножество колонок, определяемое выражением типа select a, b, c from  table , а также подмножество записей, определяемое выражением типа select a, b, c from  table  where a=100. 

Как настроить тиражирование в средах Unix и Windows NT?

            Процесс настройки и запуска тиражирования в семействе серверов Informix не сложен и сводится к настройке системной поддержки протокола SNMP на сервере и, собственно, описанию наборов и путей тиражирования данных. Если первая задача в основном выполняется вручную средствами операционной системы и является очень системно-зависимой, то для выполнения последней компанией Informix предлагается графическая утилита Enterprise Replication Manager, позволяющая описывать и управлять всеми процессами  репликации с одного рабочего места. 
            Поскольку существует огромное количество операционных систем и их версий, под управлением которых работают сервера Informix, в дополнение к стандартной документации для каждой версии продукта и операционной системы Informix выполняет документы Release Notes, описывающие все  тонкости  настройки продуктов Informix в данном окружении. Как правило, они находятся в каталоге $INFORMIXDIR/release и содержат детальное описание процессов инсталляции, настройки, описание известных ошибок в этой версии ОС, которые так или иначе могут повлиять на работу сервера, способы их обхода, номера  заплаток  к ним и т.д. Так и в случае с настройкой тиражирования достаточно просто прочитать этот документ и шаг за шагом проделать то, что там написано, а если что-нибудь, в конце концов, не выходит, обращайтесь к нам, в службу технической поддержки компании Informix.  Ответы записал   Константин РОСКОВШЕНКО,   Компьютеры+Программы  

 

Украинская баннерная сеть
 

[Home]

Сайт поддерживается группой пользователей Информикс на Украине.

Hosted by NO-more.