Сравнение базы данных Oracle RAC Cluster (10gR2, 11gR2 и 12cR1) и развернутой базы данных Oracle в Linux Cluster

896
user3134198

Внедрение Oracle RAC может быть дорогостоящим для небольшого предприятия, но как это будет, если будет реализован кластер Linux, а затем развернута стандартная база данных Oracle в этом кластере для достижения доступности, подобной Oracle RAC?

  • Можно ли добиться автоматического переключения при сбое, балансировки нагрузки и т. Д. В кластере Linux? Если один узел выходит из строя, все равно служба БД Oracle будет обслуживаться существующими и новыми соединениями?

  • Какие могут быть преимущества и недостатки?

0
Может быть, больше на тему для [dba.SE], но только если просят фактические и конкретные вещи, а не плюсы и минусы. slhck 10 лет назад 0

1 ответ на вопрос

1
Sami Laine

Вопрос скорее всего привлечет ответы, основанные на мнении. Это одна из них.

Балансировка нагрузки не может быть легко доступна, если вы запускаете процесс Oracle DB как службу в кластере Red Hat. Лучшее, что вы можете сделать, когда дело доходит до кластеризации, это активный режим ожидания, т.е. в любой конкретный момент времени процессы БД Oracle будут выполняться только на одном из узлов кластера, а в случае сбоя процессы переключаются на другой узел. Даже это может оказаться довольно трудным для выполнения, хотя.

Причина, по которой сценарий балансировки нагрузки неосуществим в этом случае, заключается в том, что наличие более одного процесса Oracle DB, обращающегося к разделам данных без их ведома друг о друге, может повредить ваши данные. В настоящее время способ информировать узлы друг о друге на уровне БД Oracle - это купить RAC, поэтому они продают его.

Тем не менее, конфигурация активного ожидания может выглядеть примерно так: привязать процессы БД Oracle к дополнительному IP-адресу, который затем перемещается от узла к узлу со службой, т.е. IP-адрес службы, процессы базы данных Oracle и разделы данных являются службами в кластере Red Hat, проходя от узла к узлу при сбое. Сервисный IP дает вам одно преимущество: таким образом ваши клиенты могут восстановить соединение, когда один из узлов выходит из строя, а другой занимает его место. Тем не менее, все существующие соединения будут разорваны во время переключения в сценарии активного ожидания.

Помимо недостатков, перечисленных выше, есть и другие проблемы, например, будет сложно получить поддержку от Oracle, если что-то пойдет не так, как вы думаете, сценарий, который вы не считаете рекомендованным Oracle.

Подводя итоги, можно подумать о том, чтобы пересмотреть решение, и, если вам действительно требуется балансировка нагрузки на уровне базы данных Oracle и т. Д., Вам, вероятно, лучше купить RAC, чем пытаться создать собственное решение, имитирующее некоторые функции, предлагаемые RAC.