Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Простое и стобильное решение для авейлабилити?  [new]
Вкусно поевший
Guest
Ну вот у меня два сервака и каждый в разных дата-центрах. Как мне наиболее проще организовать высокую доступность. Например в одном дата-центре здесь 5 минут не работает сеть, в другом ничайно отключили питалово к стойке...

У меня мало изменений данных, почти все операции это селекты с группировками, сортировками.

Пока работает стендбай с онлайн накатом логов (моментально). Сейчас задумываюсь об автоматизации процеса переключения стендбая ( на каждом серваке запущен в кроне скрипт который мониторит другой сервак и если он не доступен, то переводит локальную базу в праймари. + к этому сделаю третий виртульный сервер типа голосующего, чтобы не получить две праймари.

Всё это не то. Хочется простого, элегантного и легко управляемого решения. Почитал а раках... захотелось пить. Почитал о репликации... мульти-мастер репликашен, попробовал по настраивать... глючная, сложная в управлении штуковина. Пришла идея сделать свой собственный кластер, в котором всё просто и понятно... сделаю схему my_super_cluster, в ней сделаю табличку в которой буду хранить все изменения в других таблицах, и джабом по линку буду качать данные от сюда туда, и от туда сюда. И в этой же схеме сделаю таблицу где разделю всех пользователей на мужчин и женщин, прямоходящих и ползующих. И пусть пользователи по левую руку конектятся к левой базе, а те что с права пусть идут на правую.

Хочется сделать удобное и главное стабильное решение.
22 июл 10, 19:03    [9146602]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
-Доктор-
Guest
Вкусно поевший
Ну вот у меня два сервака и каждый в разных дата-центрах. Как мне наиболее проще организовать высокую доступность. Например в одном дата-центре здесь 5 минут не работает сеть, в другом ничайно отключили питалово к стойке...

У меня мало изменений данных, почти все операции это селекты с группировками, сортировками.

Пока работает стендбай с онлайн накатом логов (моментально). Сейчас задумываюсь об автоматизации процеса переключения стендбая ( на каждом серваке запущен в кроне скрипт который мониторит другой сервак и если он не доступен, то переводит локальную базу в праймари. + к этому сделаю третий виртульный сервер типа голосующего, чтобы не получить две праймари.

Всё это не то. Хочется простого, элегантного и легко управляемого решения. Почитал а раках... захотелось пить. Почитал о репликации... мульти-мастер репликашен, попробовал по настраивать... глючная, сложная в управлении штуковина. Пришла идея сделать свой собственный кластер, в котором всё просто и понятно... сделаю схему my_super_cluster, в ней сделаю табличку в которой буду хранить все изменения в других таблицах, и джабом по линку буду качать данные от сюда туда, и от туда сюда. И в этой же схеме сделаю таблицу где разделю всех пользователей на мужчин и женщин, прямоходящих и ползующих. И пусть пользователи по левую руку конектятся к левой базе, а те что с права пусть идут на правую.

Хочется сделать удобное и главное стабильное решение.

вот здесь есть отличное решение
22 июл 10, 19:17    [9146649]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
DataGuard Broker
Fast-Start Failover + Observer
23 июл 10, 02:25    [9147626]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Вячеслав Любомудров
DataGuard Broker
Fast-Start Failover + Observer


Как он собирается решать сплит-брейн проблему, мне интересно, если у него 2 независимых центра???

А так - не нужно изобретать велосипед, с тем же OEM вся эта суперзадача делается с нуля за пару часов - и автопереключение базы, и возврат ее обратно, и бэакпный обзервер, и перезапуск обзервера (кстати, без ОЕМ обзервер перезапустить можно лишь ручками), и возможность написать хитрые правила когда нужно делать ФайлОвер, и триггеры обеспечивающие переключение клиентов (их правда нужно руками настукать) - кодовое гугловое слово Oracle MAA

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

Все это давно известно и скажем у нас делается без раздумий просто парой мышетыканий, если очень нужно... и проверялось неоднократно...
23 июл 10, 03:19    [9147645]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
И всех супер решений
- ставим 3 сервера. На 2 оракл базу, на 3-й ставим OEM
- на все серверы ставмим агентов OEM
- создаем базу на первом, делаем удобные имена скажем

db1 - база, db1p - SID и UNIQ_NAME

- в ОЕМ просим создать стендбай на втором. Имя db1, SID db1s, уник имя db1s

- когда база создана, и там и там ставим автозапуск в oratab

- в OEM просим теперь сделать ее Fast failover. Указываем место где будет стоять обзервер.

- в базе создаем триггер который выставляет имя сервиса (скажем db1_s) на праймари и убирает на стендбае.

Тестируем свитчовер, тестируем файловер, отдаем клиенту. ВСЕ. ВСЕ РАБОТАЕТ. Ничего изобретать не пришлось (один небольшой глюк руками убираем - управление файлами ставим в AUTO в дата гард брокере).

И никаких тебе мокрых спин, бессонных ночей, сложнейших команд (в одном месте пользуемся sqlplus - там где триггер нужно создать... в остальных просто мышкой тыкаем в OEM). И чего народ так любит мазохизмом заниматься, я никогда не мог понять...
23 июл 10, 03:24    [9147648]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Hard Core
Guest
Alex Roudnev
И чего народ так любит мазохизмом заниматься, я никогда не мог понять...
Нрод в основном не знает, что все велосипеды изобретены, а иногда ленится изучать чужие велосипеды - свой и понятней и приятней (ну и пусть, что не едет )
23 июл 10, 11:00    [9148663]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Народ обычно знает...
А вот некоторые, наверное не знают, что две кнопки в GC реализуют именно DG Broker+Observer
Я не ратую за "мазохизм", но разобраться, какие шестеренки там вертятся бывает полезно
26 июл 10, 05:17    [9156073]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Прекрасное далёко
Guest
Так это всё предлагается отказоустойчивость и авейлабилити, а где производительность и балансировка нагрузки.

Допустим нам надо:
1) Один сервер не справляется с нагрузкой. Всего у нас два сервера.
2) Надо разделить нагрузку и если один завалится быстренько перекинуть пользователей на другую базу.

Получается что, самое крутое решение это реплекация?

Потому что датагард - это один сервер максимум а остальные не работают, а только ждут своего часа.
Потому что рак- это не то, так надо в разных датацентрах хранить базы. Иначе питалово к той же стойке сделает рак one point of failure. И усё.

Репликация рулит?
9 авг 10, 04:08    [9231796]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Прекрасное далёко
Допустим нам надо:
1) Один сервер не справляется с нагрузкой. Всего у нас два сервера.
2) Надо разделить нагрузку и если один завалится быстренько перекинуть пользователей на другую базу.

Получается что, самое крутое решение это реплекация?
Имеется в виду двусторонняя репликация? Т.е. если раньше просто работал один сервер, то теперь он еще получает логи другого/обрабатывает очередь, применяет изменения? Так это не балансировка нагрузки, а увеличение нагрузки. Да и не уверен что есть промышленное решение для двусторонней репликации без гиморроя с разруливанием коллизий. Так что остается RAC, но если один сервер не справляется, что нельзя решить ситуацию апгрейдом, то скорее всего приложение написано так, что в RAC все станет еще хуже.
9 авг 10, 04:34    [9231806]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Прекрасное далёко
Потому что рак- это не то, так надо в разных датацентрах хранить базы. Иначе питалово к той же стойке сделает рак one point of failure. И усё
Ну есть еще extended RAC.
9 авг 10, 04:45    [9231808]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Прекрасное далёко
Потому что датагард - это один сервер максимум а остальные не работают, а только ждут своего часа.
Active data guard.
9 авг 10, 04:49    [9231809]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Прекрасное далёко
Guest
wurdu
Active data guard.


вооо!!!!!!! то что нужно! Почитал об активДатагард это просто идеальное решение в моём случае (99% нагрузки у меня это мощные селекты).
9 авг 10, 06:06    [9231823]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Gallagher
Member

Откуда: ( ͡°◞ʖ◟ ͡°)
Сообщений: 542
logical standby
9 авг 10, 11:44    [9233117]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Пробовал?
Насколько оно надежно?
В 9-ке оно было совсем кривое, дальше не знаю
9 авг 10, 11:51    [9233181]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

Прекрасное далёко
(99% нагрузки у меня это мощные селекты).

И именно поэтому wurdu неправ, говоря "Т.е. если раньше просто работал один сервер, то
теперь он еще получает логи другого/обрабатывает очередь, применяет изменения? Так это не
балансировка нагрузки, а увеличение нагрузки." Select в логах не идёт, так что нагрузочная
способность кластера на репликации определяется только производительностью каждой
отдельной ноды по DML. В твоём случае, чтобы дойти до предела, понадобится кластер из ста нод.

Posted via ActualForum NNTP Server 1.4

9 авг 10, 12:24    [9233474]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Мафиози
Guest
Dimitry Sibiryakov, так открытый стендбай всегда лучше мультимастер репликации. Нет ниакого гемороя.
9 авг 10, 13:27    [9234144]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

Мафиози

так открытый стендбай всегда лучше мультимастер репликации. Нет ниакого гемороя.

С мультимастер репликацией я наблюдаю только один геморрой - генерацию
глобально-уникальных ключей, что на счёт "раз" решается применением GUID. Чего я не заметил?

Posted via ActualForum NNTP Server 1.4

9 авг 10, 13:37    [9234242]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Dimitry Sibiryakov

Мафиози

так открытый стендбай всегда лучше мультимастер репликации. Нет ниакого гемороя.

С мультимастер репликацией я наблюдаю только один геморрой - генерацию
глобально-уникальных ключей, что на счёт "раз" решается применением GUID. Чего я не заметил?


Конфликты как разрешать будем? Я на одном сервере вам зарплату задал 100 рублей а на втором 1000, как они решат, какое изменение реплицировать а какое похерить?
10 авг 10, 01:38    [9237444]     Ответить | Цитировать Сообщить модератору
 Re: Простое и стобильное решение для авейлабилити?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51780

Alex Roudnev

Конфликты как разрешать будем? Я на одном сервере вам зарплату задал 100 рублей а на
втором 1000, как они решат, какое изменение реплицировать а какое похерить?

По времени. По приоритету. От балды.

Гораздо интереснее вопрос: как покарать оператора, введшего неверные данные. Впрочем,
ответ на него не зависит от того единая база или распределённая.

Posted via ActualForum NNTP Server 1.4

10 авг 10, 11:44    [9239031]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить