Комментарии 4
Что мешало просто поднять standby Oracle и использовать его как кэш? Или реплицировать в cache-Oracle избранные таблицы через GG. Структура таблиц ведь осталась та же? Зачем весь этот геморрой с перекачкой 2.5 Tb через csv-файлы? А «прогрев» — просто востановление из бекапа вообще без нагрузки на master-Oracle, да и не нужен он будет на практике почти никогда. И изменения в DDL автоматом бы реплицировались. Для Oracle 10 Тыс запросов в секунду это семечки, если речь идет о мелких запросах, типичных для OLTP.
Как бы лицензия Oracle стоит вполне конкретных денег на каждое ядро, плодить инстанции Oracle довольно накладно
Mur466 раньше так и делали. Был выделенный standby для чтения. Чем нас не устраивало это решение: Oracle периодически уходит в maintenance, нет георезерва, держать дополнительные инстансы ORACLE накладно.
Мы решали еще и задачу отказоустойчивости и независимости контура. Tarantool имеет георезерв. Теперь все обновления нашего сервиса проходят без простоя. Последний раз грели кэш в проде год назад. И это рутинная операция. Регулярно тренируемся в прогреве на стенде нагрузочного тестирования. Запуск холодной прогрузки по кнопке, трудозатраты стремятся к 0.
В итоге, мы пожертвовали простым решением с репликацией в standby, но получили лучший TCO и отказоустойчивость.
Мы решали еще и задачу отказоустойчивости и независимости контура. Tarantool имеет георезерв. Теперь все обновления нашего сервиса проходят без простоя. Последний раз грели кэш в проде год назад. И это рутинная операция. Регулярно тренируемся в прогреве на стенде нагрузочного тестирования. Запуск холодной прогрузки по кнопке, трудозатраты стремятся к 0.
В итоге, мы пожертвовали простым решением с репликацией в standby, но получили лучший TCO и отказоустойчивость.
А бюджет проекта (стоимость разработки и 1 года поддержки) можете прикинуть? Чтобы как-то сравнить ТСО?
По надежности и отказоусточивости ИМХО ничто не сравнится с двумя разнесенными стендбаями Oracle. Тем более такая технически сложная система как описана в посте. Потенциальных точек для сбоев очень много, специалистов по самописной системе интеграции Oracle/Tarantool на рынке нет. Выглядит все очень уязвимо.
Интересно, сколько выиграли в деньгах.
По надежности и отказоусточивости ИМХО ничто не сравнится с двумя разнесенными стендбаями Oracle. Тем более такая технически сложная система как описана в посте. Потенциальных точек для сбоев очень много, специалистов по самописной системе интеграции Oracle/Tarantool на рынке нет. Выглядит все очень уязвимо.
Интересно, сколько выиграли в деньгах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кэши Tarantool и репликация из Oracle