Comments 7
Давно я не читал статей для ИТ-ников, в которых бы задавался вопрос «Понятно?» )))
При этом смысл статьи: БД — это не файлы. Файлы — это файлы, а БД — это БД. Нельзя бекапить БД путем бекапа файлов. А что делать? Нагрузка будет высокой, так что нам нужна не софтина, а программно-аппартный комплекс (Железка). И вот у нас есть такой черный ящик, который мы назвали по-простому, «Беспотерьная Железяка для Восстановления» (БЖВ). Она делает все-все, так что беспокоиться не о чем! Понятно?
Не понятно. Вы реплицируете базы с боевых серверов БД на вашу БЖВ? Круто, конечно, но я не вижу обещанного отсутствия снижения производительности боевых серверов. Репликация, более того, бывает асинхронной (думаю, в описываемом решении именно так, чтобы не тормозить «боевые» сервера еще больше), а, значит, есть риск потери последнего фрагмента данных.
Честно говоря, не понял, в чем магия. Такое, извините, на MySQL делается несложно (репликация и бекапы уже с реплики, а лучше со снапшота реплики), не говоря про более серьезные БД-решения.
При этом смысл статьи: БД — это не файлы. Файлы — это файлы, а БД — это БД. Нельзя бекапить БД путем бекапа файлов. А что делать? Нагрузка будет высокой, так что нам нужна не софтина, а программно-аппартный комплекс (Железка). И вот у нас есть такой черный ящик, который мы назвали по-простому, «Беспотерьная Железяка для Восстановления» (БЖВ). Она делает все-все, так что беспокоиться не о чем! Понятно?
Не понятно. Вы реплицируете базы с боевых серверов БД на вашу БЖВ? Круто, конечно, но я не вижу обещанного отсутствия снижения производительности боевых серверов. Репликация, более того, бывает асинхронной (думаю, в описываемом решении именно так, чтобы не тормозить «боевые» сервера еще больше), а, значит, есть риск потери последнего фрагмента данных.
Честно говоря, не понял, в чем магия. Такое, извините, на MySQL делается несложно (репликация и бекапы уже с реплики, а лучше со снапшота реплики), не говоря про более серьезные БД-решения.
На самом деле это просто статья такая мыльная:
* а тут мне лень указывать всякие детали мелким шрифтом :)
- для не ораклистов она вообще бесполезная, т.к. для того, чтобы знать в чем все-таки преимущества ZDLRA, надо знать все остальные методы HA, которые у Оракла есть со всей кучей всяких тонкостей и возможностей.
- для ораклистов она чересчур поверхностная
Такое, извините, на MySQL делается несложно (репликация и бекапы уже с реплики, а лучше со снапшота реплики), не говоря про более серьезные БД-решения.в оракле это тоже возможно и без этой железки, у ZLDRA другие преимущества из которых лично я вижу только пару:
- легкая и простая консолидация сразу кучи баз с помощью «волшебной blackbox»
- легкое быстрое получение снепшота на любой* момент времени.
* а тут мне лень указывать всякие детали мелким шрифтом :)
Да уж, прочитал и ни капли нового для себя не узнал… Все, что написано — уже сто раз обмусолено и давным давно реализовано в других СУБД. В чем уникальность именно вашего решения?
Я ж и не спорю, что в том же Оракле и реализовано :). Просто заголовок обещает какую-то новую «серебряную пулю», а под катом одни общеизвестные факты. Такое ощущение, что статью писал маркетолог, пусть с неплохим знанием матчасти, но все же маркетолог.
Sign up to leave a comment.
Как перестать беспокоиться о резервном копировании, или Oracle Zero Data Loss Recovery Appliance