Комментарии 6
В статье ничего лишнего, нет даже описания проблемы.
[ режим зануды ON]
Stream как и любая репликация больше не для отказоустойчивости, а для передачи данных на «большие» расстояния. Если вас интересует только отказоустойчивость, то тогда не понятно зачем репликация двухсторонняя, судя по схеме. Скрипты не читал, так как пока нет времени. Это же лишние проблемы со встречными транзакциями и конфликтами.
Для отказоустойчивости на SE, где нет STAND BY, я бы делал примерно так:
Физическая копия + скрипт в кроне:
rsync директории арх логов, recover database.
Статья хорошая, даёт повод новичкам почитать про Stream, так как кроме скриптов в статье почти ничего не написано.
[ режим зануды OFF]
[ режим зануды ON]
Stream как и любая репликация больше не для отказоустойчивости, а для передачи данных на «большие» расстояния. Если вас интересует только отказоустойчивость, то тогда не понятно зачем репликация двухсторонняя, судя по схеме. Скрипты не читал, так как пока нет времени. Это же лишние проблемы со встречными транзакциями и конфликтами.
Для отказоустойчивости на SE, где нет STAND BY, я бы делал примерно так:
Физическая копия + скрипт в кроне:
rsync директории арх логов, recover database.
Статья хорошая, даёт повод новичкам почитать про Stream, так как кроме скриптов в статье почти ничего не написано.
[ режим зануды OFF]
Минусом реализации отказоустойчивости через арх логи является необходимость нахождения (выезда) человека на объекте, способного, в случае отказа основного узла, в короткие сроки вывести резервный узел из READ ONLY в PRIMARY, и после починки основного узла вернуть как было. Здесь можно просто переключиться на второй узел и продолжить работу. Проблемы с конфликтами транзакций, опять же возникают не во всех схемах работы, в данной конфигурации за верное значение берется последнее введенное (compare_key_only).
Польза статьи как раз и задумывалась, как польза в скриптах, т.к. теория то понятна и не сильно забывается, но когда доходит дело до конкретной реализации, которая не находится быстро в поисковике, то уходит много времени, тем более, если делать это приходится раз в пару лет.
Польза статьи как раз и задумывалась, как польза в скриптах, т.к. теория то понятна и не сильно забывается, но когда доходит дело до конкретной реализации, которая не находится быстро в поисковике, то уходит много времени, тем более, если делать это приходится раз в пару лет.
Все замечательно, но вы не описали самое интересное — сценарий действий в случае отказа основного узла, ради которого Streams и затевался. Где выгода в сравнении с «ручным» стендбаем?
По моему опыту, сама по себе технология stream не самая надежная, в ней множетсво подводных камней и неожиданных сюрпризов.
Как я понял, в вашей конфигурации есть основной сервер и резервный.
Зачем репликация данных в обе стороны, достаточно с основного на резервный?
Как я понял, в вашей конфигурации есть основной сервер и резервный.
Зачем репликация данных в обе стороны, достаточно с основного на резервный?
Да, есть новая технология — GoldenGate, которая будет уметь/умеет делать то же самое, но за отдельные деньги.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка двухсторонней синхронизации БД Oracle (Oracle Streams)