В предыдущем посте я рассказал о различиях между двумя технологиями Oracle — High Availability и Disaster Recovery. В втором посте серии, мы поговорили о том, как SharePlex может помочь в аварийном восстановлении. В этом заключительном посте я расскажу, как Quest SharePlex может обеспечить основу для системы высокой доступности без сложностей Oracle RAC.
Одной из основных особенностей SharePlex является то, что он выполняет репликацию базы данных на логическом уровне или уровне транзакции SQL. Целевая база данных SharePlex всегда доступна в полном режиме чтения / записи.
Еще одно преимущество использования SharePlex для обеспечения высокой доступности состоит в том, что можно легко избежать единичных точек отказа. В отличие от Oracle RAC, где база данных или физическое хранилище совместно используются, SharePlex реплицируется в полностью отдельную целевую базу данных, тем самым избегая использования общего хранилища.
При использовании SharePlex, вместо определений первичной или вторичной базы данных, мы используем термины «источник» и «цель», поскольку все базы данных в среде репликации SharePlex открыты и находятся в режиме чтения / записи. В этой части серии я буду использовать понятие «источник» для определения первичной базы данных и «цель» определения базы данных, которая будет поддерживать высокую доступность.
Вот некоторые вещи, которые следует учитывать при использовании цели SharePlex для обеспечения высокой доступности:
Первым шагом при настройке репликации в 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. Пилотные проекты и референсные встречи мы также проводим, пожалуйста, обращайтесь.