Комментарии 14
Хм, странная база, которая не поддерживает инкрементальный бэкап, но поддерживает объемы в 20ТБ.
Мож тут снеэпшоты помогут, но поскольку непонятно, что за зверь, да еще такой странной породы — то и советовать-то по сути нечего.
Мож тут снеэпшоты помогут, но поскольку непонятно, что за зверь, да еще такой странной породы — то и советовать-то по сути нечего.
По своему опыту администрирования oracle >20Тб могу сказать, что самый лучший вариант бэкапа — split mirror на уровне дисковых массивов (HP,Hitachi...).
Копия синхронизируется с основной БД с использованием внутренних механизмов массивов с минимальной нагрузкой на БД. Далее выполняется begin backup для online бэкапа или shutdown для холодного на БД и split копии на массиве.
При необходимости восстановления можно подняться с копии (что не очень хорошо, т.к теряется бэкап) либо выполнить обратную синхронизацию с копии на основные группы и затем подняться.
В такой конфигурации бэкап и восстановление укладываются в несколько минут.
Из минусов — при online бэкапе не должен идти ASM rebalance и для datafiles весьма желателен autoextend off. И еще очевидный минус — дисков надо много :)
Копия синхронизируется с основной БД с использованием внутренних механизмов массивов с минимальной нагрузкой на БД. Далее выполняется begin backup для online бэкапа или shutdown для холодного на БД и split копии на массиве.
При необходимости восстановления можно подняться с копии (что не очень хорошо, т.к теряется бэкап) либо выполнить обратную синхронизацию с копии на основные группы и затем подняться.
В такой конфигурации бэкап и восстановление укладываются в несколько минут.
Из минусов — при online бэкапе не должен идти ASM rebalance и для datafiles весьма желателен autoextend off. И еще очевидный минус — дисков надо много :)
Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии.
А к чему такая дикая секретность? Не проще сказать, типа MySQL, версия 3.21...???
А к чему такая дикая секретность? Не проще сказать, типа MySQL, версия 3.21...???
Понятно, что зеркало спасает от аппаратного сбоя, но если данные испорчены программно (неудачное изменение структуры или ошибочный запрос, который обнулил все счета клиентов), то тут лучше иметь копию, в которую эти изменения не попали.
Может быть, стоит зеркало нагружать (инкрементальными) бэкапами?
Может быть, стоит зеркало нагружать (инкрементальными) бэкапами?
Да, мы тоже думали об этом и решили, что вообще без бэкапа существовать невозможно, так как может произойти такая ситуация, когда, действительно, данные могут быть испорчены программно и необходимо откатится назад во времени. Но по двум причинам:
1. большой объем
2. это хранилище данных, т.е. не операционная база данных
решили делать их достаточно редко. Также эти бэкапы восстанавливаются достаточно долго, бизнес не может ждать несколько дней и нужен метод, который позволил бы в случае аппаратного сбоя быстро перейти на зеркало.
1. большой объем
2. это хранилище данных, т.е. не операционная база данных
решили делать их достаточно редко. Также эти бэкапы восстанавливаются достаточно долго, бизнес не может ждать несколько дней и нужен метод, который позволил бы в случае аппаратного сбоя быстро перейти на зеркало.
Как уже заметили в комментариях, резервные копии(backups) нужны не только и не столько для восстановления после сбоя системы(HW), сколько для восстановления после человеческих ошибок или преднамеренных действий. Восстановить данные которые были испорчены «по всем правилам». От потери железа спасает replication/mirroring, желательно на сильно удаленный (200км) дисковый массив или БД. То есть жить без бэкапов можно, но «ленты» в сейфе спасают от большого количества проблем. Обычно в высоко нагруженных системах используют схему. Primary storage --> replication --> Secondary storage --> backup --> backup hw. Для OLAP систем это точно работает. Secondary storage нагружается только в момент загрузки данных и пока идет обработка основных данных на primary мы делаем backup c secondary.
Вы меня опередили.
Действительно, это будет самое верное решение снимать копию со второго data storage.
Обычно эти data storage сами умеют делать snapshot данных, причем очень быстро.
По крайне мере у нас с hp 2000 проблем нету.
Действительно, это будет самое верное решение снимать копию со второго data storage.
Обычно эти data storage сами умеют делать snapshot данных, причем очень быстро.
По крайне мере у нас с hp 2000 проблем нету.
Автор пишет про GreenPlum, это shared nothing MPP система, нет никакого общего стореджа который можно реплицировать\снепшотить.
20ТБ серьезные объемы, что за организация если не секрет?
20ТБ серьезные объемы, что за организация если не секрет?
Да, действительно, общего стореджа нет (как это понимается в Oracle), но можно использовать единый дисковый массив, есть и табличка с информацией, где что лежит, так что варианты с replication/mirroring есть.
Пока официального пресс-релиза не было и я не могу разглашать имя организации. Могу сказать, что это один из банков.
Пока официального пресс-релиза не было и я не могу разглашать имя организации. Могу сказать, что это один из банков.
Хотя, можно делать snaps на втором массиве, если совсем никак сделать бэкапы.
Ваша беда никак не даёт мне покоя. EMC предлагает два основных решения для бэкапа Гринплама — Data Domain и VNX. Вы смотрели вайт-пэйперы об этом?
Да, смотрели. Решения хорошие, за одним исключением — стоят дорого. По сравнению с ними NFS шара стоит копейки. И даже ddboost, и data deduplication не оправдывает такой стоимости — за такие деньги можно купить кучу дисков и использовать их. Хотя, повторюсь, решения хорошие и на них можно построить отличную схему резервного копирования, если использовать DD Replicator.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Big Data: Backup делать нельзя работать без него