Этот сайт посвящается администрированию баз данных OpenEdge Progress.
Не корысти ради, а познания для!
С уважением,
Валерий Башкатов
|
Сайт разработан при участии компании Progress Technologies, официального дистрибьютора Progress Software Corp. на территории стран СНГ и Латвии.
На сайте функционирует система коррекции ошибок. Обнаружив неточность в тексте, выделите её и нажмите Ctrl+Enter
Результаты опроса: Нужны ли книги по Progress OpenEdge на русском языке? (опрос проводился с мая 2009 по ноябрь 2010)
Да, нужны. Потому что будет легче понять материал - 268
Нет, не нужны. Достаточно материалов на английском языке - 10
Не знаю, мне всё равно - 6
А знаете ли вы что..
|
|
|
Защита данных - Репликация данных
Репликация данных
Основы баз данных OpenEdge
Защита данных
Стратегия резервного копирования (backup)
Востановление базы данных
After-imaging
Обеспечение безопасности
Auditing
Репликация данных
Схемы репликации
Репликация с использованием триггеров
Централизованное копирование
Репликационные модели
Модели связей базы данных
Модель распределения данных
Консолидированная модель
Одноранговая модель
Выполнение централизованной репликации
Failover Clusters
Поддержка и мониторинг базы данных
Команды запуска и останова
Параметры запуска баз данных
Утилиты OpenEdge RDBMS
Виртуальные системные таблиц (VST)
Репликация данных это процесс копирования информации на один или более серверов. В некоторых организациях, имеется территориально распределенные сервера, и условия бизнеса требуют их периодической синхронизации. Разработка и внедрение процессов репликации требует составления детального плана и участия бизнес аналитиков, разработчиков приложений и администраторов.
Схемы репликации
Репликационная схема это набор определенных задач и операций используемых для репликации данных. Схема репликации данных предприятия основывается на требованиях бизнеса. В этой части объединяются различные модели репликации, модели монопольного использования данных и доступные стратегии реализации. Репликационные схемы могут быть выполнены с помощью триггеров или с использованием централизованного копирования.
Репликация с использованием триггеров
Механизм копирования на основе триггеров использует триггеры хранимые в базе данных. Когда происходит событие подлежащее копированию (это может быть создание, изменение или удаление записи), база данных использует это события для записи изменений в репликационный журнал изменений. ABL полностью поддерживает работу с репликационными триггерами. Для получения более подробной информации об использовании репликационных триггеров смотрите OpenEdge Development: ABL Handbook
Централизованное копирование
Централизованное копирование основывается на мониторе, который отслеживает изменения в журнале транзакций и копирует эти изменения на другие сервера. Журнал транзакций генерируется базой данных и включает в себя любые изменения созданных транзакциями. Это очень эффективный способ копирования данных с сервера на сервер. Так же появляется возможность удаленного резервного копирования первичной базы данных. OpenEdge RDMS поддерживает репликацию используя after-image (AI) файлы. Более подробно этот механизм будет описан в «Выполнение централизованной репликации».
Репликационные модели
Существует две модели репликации: синхронная и асинхронная.
При синхронной репликации, данные копируются в пределах одной транзакции. Или другими словами можно сказать, копирование происходит транзакция к транзакции. Обычно, эту модель использует протокол two-phase commit. Этот протокол гарантирует, что транзакция пройдет последовательно по всем базам данных. Поскольку изменения происходят в пределах одной транзакции, синхронная репликация гарантирует высокую надежность и целостность данных. Такая транзакция либо будет принята во всех базах, либо будет отвергнута везде.
Асинхронная репликации копирует данные вне области транзакции. Копирование может происходить в течении секунд, минут, часов и даже дней, в зависимости от требований бизнеса. Хотя репликация выполняется запись в запись, она может происходить и по транзакциям. Т.е., если происходят множественные изменения в пределах одной транзакции, они могут скопироваться как одна транзакция.
Модели связей базы данных
Модели связей баз данных определяют, каким образом изменения в одной базе влияют на изменения других баз в сети. Ниже описаны три такие модели: распределения данных, консолидации данных и одноранговая модель, а также как они связаны с репликацией.
Модель распределения данных
В распределенной модели, только одна база данных является основной. Все изменения происходят именно в этой базе. Данные копируются из нее в остальные базы в сети и имею статус «только для чтения», т.е. запрещено вносить изменения в них. С точки зрения репликации, главное преимущество этой модели то, что это существенно уменьшает возможность конфликтов при изменении записей, т.к. изменения происходят только в одной базе данных.
На рисунке показа схема распределенной модели данных:
Консолидированная модель
Консолидированная модель – это когда данные с удаленных баз копируются в центральную. Центральная база данных находится в режиме «только для чтения» и используется только для формирования отчетности. С точки зрения репликации, эта модель увеличивает вероятность конфликтов при изменении записей. Если возникают конфликты изменений, то изменения принимаются по принципу «первый пришел, первый обслужился».
С целью исключения конфликтов, таблицы базы данных должны иметь так называемою табличную разметку (table partitioning). Табличная разметка определяет принадлежность данных к определенной базе данных. Изменения сделанные на удаленной базе, должны производиться исключительно пользователем этой базы. Такая модель не может соответствовать требованиям бизнеса, т.к. в этом случае теряется возможность изменения одной записи с различных баз данных.
Следующий рисунок иллюстрирует две модели консолидации, без монопольного доступа к данным и с использованием табличной разметки:
Одноранговая модель
В одноранговой модели каждый пользователь может вносить изменения в любой базе сети. Эта наиболее гибкая модели репликации. Тем не менее, конфликты данных здесь имеют место, и могут быть решены различными способами, в зависимости от требований бизнеса. Следующий рисунок показывает схему одноранговой модели:
Выполнение централизованной репликации
При централизованной репликации, центральная база данных копируется на множество целевых баз данных. Централизованная репликация позволяет следующее:
- Создание резервных баз данных в реальном времени.
- Гибкая возможности контроля времени репликации
- Прозрачный способ удаленного резервного копирования первичной базы данных
Репликация осуществляется средствами after-image файлов и резервной копии центральной базы.
Для выполнения централизованного копирования необходимо:
1. Добавить AI экстенты и активируйте after-imaging на центральной базе.
2. Использовать утилиту PROSTRCT с опцией LIST для создания структурного файла содержащего структуру центральной базы.
3. С помощью PROSTRCT CREATE и на основании созданного структурного файла, создайте новую базу данных на удаленной машине.
4. Сформируйте резервную копию центральной (исходной) базы данных. Эта копия будет основанием для последующего использования механизма roll-forward.
5. Восстановите копию исходной базы на целевую
6. Используйте команду RFUTIL EXTENT FULL для мониторинга AI экстентов. Которая автоматически определит какой экстент готов для передачи на целевую базу. После чего вы можете скопировать заполненный ai экстент на удаленную копию средствами операционной системы.
7. После копирования экстента, воспользуйтесь командой RFUTIL EMPTY с целью перевода экстента в статус «EMPTY», для дальнейшей возможность его использования базой данных.
8. Во время копирования ai экстентов ведите журнал регистрации скопированных ai файлов.
9. В случае возникновения необходимости использовании целевой базы с внесением изменений в нее, скопируйте последние заполненные (full) и занятые (busy) экстенты и завершите процесс наката. После чего целевую запустите базу данных. При этом будет выполнен механизм crash recovery, для осуществления отката не завершенных транзакций.
В завершении нельзя не сказать о имеющемся в OpenEdge RDBMS механизме автоматической репликации OpenEdge Replication. Которой значительным образом упрощает работу администратора базы данных, освобождая его от большого количества ручной работы и использования самописных скриптов. OpenEdge Replication это целая отдельная тема для разговоров, которая в данной книге будет затронута.
|
|
|
|
Главная
