Одной из основных особенностей SharePlex является то, что он выполняет репликацию базы данных на логическом уровне или уровне транзакции SQL. Целевая база данных SharePlex всегда доступна в полном режиме чтения / записи.
Еще одно преимущество использования SharePlex для обеспечения высокой доступности состоит в том, что можно легко избежать единичных точек отказа. В отличие от Oracle RAC, где база данных или физическое хранилище совместно используются, SharePlex реплицируется в полностью отдельную целевую базу данных, тем самым избегая использования общего хранилища.
Настройка SharePlex для высокой доступности
При использовании SharePlex, вместо определений первичной или вторичной базы данных, мы используем термины «источник» и «цель», поскольку все базы данных в среде репликации SharePlex открыты и находятся в режиме чтения / записи. В этой части серии я буду использовать понятие «источник» для определения первичной базы данных и «цель» определения базы данных, которая будет поддерживать высокую доступность.Вот некоторые вещи, которые следует учитывать при использовании цели SharePlex для обеспечения высокой доступности:
- Используйте псевдоним TNS вместо соединения BEQUEATH для баз данных. Это немного упростит аварийное переключение и обратную репликацию.
- Используйте псевдоним TNS, отличный от созданного на шаге 1 и виртуальный IP-адрес или имя хоста для исходной базы данных. Используйте это в приложениях, чтобы упростить переключение с источника на цель.
- Рассмотрите возможность настройки «обратной» репликации от цели к источнику. Это позволит захватывать транзакции, примененные к цели после отработки отказа, и упростить возврат к источнику без потери данных.
- Вы можете рассмотреть возможность использования аппаратных или программных балансировщиков нагрузки, чтобы помочь автоматизировать фактический процесс аварийного переключения.
Первым шагом при настройке репликации в SharePlex является создание экземпляра целевого объекта с теми же данными, что и в источнике. В админгайде SharePlex можно найти рекомендации о том, как добиться этого без простоев с помощью инструментов Oracle, таких как, например, RMAN.
После создания экземпляра целевой базы данных нужно будет создать конфигурацию или файл конфигурации. Если вы хотите реплицировать целые схемы, вы можете использовать функцию EXPAND с подстановочными знаками, чтобы реплицировать каждую схему в одной строке. Например, для репликации схемы GL файл конфигурации будет выглядеть примерно так:
EXPAND GL.% GL.% <Target HostName> @o. <TargetDB TNS ALIAS>
После активации файла конфигурации транзакции будут передаваться от источника к цели, и цель будет готова к использованию.
Настройка систем и приложений для аварийного переключения
Как упоминалось выше, вам нужно использовать псевдонимы TNS как для исходной, так и для целевой базы данных. Также нужно настроить «виртуальный» псевдоним TNS и IP-адрес, которые перемещаются между исходным и целевым серверами / базами данных. Этот третий псевдоним — тот, на который нужно натравливать приложения.Проверка доступности / обнаружение сбоя
Также понадобится какая-то проверка доступности или обнаружение сбоев; так чтобы сценарий или программа на цели могли обнаружить сбой на источнике. Например, сетевой ping, tnsping или удаленный доступ к базе данных.Отказоустойчивость
Когда цель обнаруживает сбой, сценарий должен попытаться закрыть подключение к источнику (чтобы избежать сетевых конфликтов), изменить виртуальный псевдоним, чтобы он указывал на цель, и, если он настроен, начать репликацию от цели обратно к источнику. Возможно, также нужно отправить электронное письмо или какое-либо предупреждение.Использование балансировщика нагрузки
В случае сбоя, приложения обнаружат отключение от одной базы данных, поэтому потребуется повторное подключения и сценарий аварийного переключения. Потребуется немного времени, обычно меньше секунды, чтобы обнаружить сбой и изменить виртуальный IP-адрес или псевдоним базы данных. Поскольку задействованы две отдельные базы данных, а SharePlex использует асинхронную репликацию, существуют сценарии аварийного переключения, которые могут привести к потере небольшого количества зафиксированных транзакций. Однако, можно настроить в SharePlex обнаружение таких кейсов и, после восстановления исходной исходной базы данных, выполнить повторную синхронизацию. Если нужно более короткое время восстановления или больше прозрачности, можно рассмотреть возможность использования RAC, дополненного SharePlex.Тест
Пока системы высокой доступности не будут протестированы в реальных условиях, никогда нельзя быть уверенным, что все будет работать так, как планировалось. Последний этап плана должен заключаться в тестировании аварийного переключения, по крайней мере, один раз, а возможно, и больше. После того, как протестировано аварийное переключение, можно расслабиться, выполнив или превзойдя самые смелые SLA.Другие посты серии:
High Availability vs Disaster Recovery (часть 1)
Disaster Recovery для Oracle при помощи инструмента для репликации Shareplex (часть 2)
Пишем на Хабре:
Сравнение Shareplex с Oracle GoldenGate
Дополнительные вопросы относительно Shareplex вы можете задать через форму обратной связи на нашем сайте или другим удобным способом. Решение доступно в триальной версии, вы можете его попробовать, оценить возможности или сравнить с вашим текущим средством для репликации Oracle. Пилотные проекты и референсные встречи мы также проводим, пожалуйста, обращайтесь.
