Big Data: Backup делать нельзя работать без него

    За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.

    Недавно перед нами была поставлена задача – разработать процедуру резервного копирования хранилища данных размером в 20 Терабайт. Используя наработанные практики резервного копирования, я попытался разработать такую процедуру и уложиться в то же время в рамки RPO (recovery point objective) и RTO (recovery time objective). Обе эти характеристики измеряются во времени и представляют собой следующее: RPO – допустимый объем возможных потерь данных, RTO – допустимое время простоя или за какое время база данных должна восстановиться. Вот тут-то и началось самое интересное – как бы я не прикидывал и не рассчитывал, но разработанная процедура резервного копирования никак не желала укладываться в эти рамки – слишком большой объем данных надо было забэкапить. В самом лучшем случае, с многочисленными оговорками и условиями база данных восстанавливалась за несколько часов, а такого бизнес себе позволить не мог. В обычной же ситуации, когда на базу данных не налагались серьезные ограничения и условия, восстановление заняло бы несколько дней. Это усугублялось тем, что невозможно «снять» бэкап за приемлемое время – это также занимало несколько дней и создавало большую нагрузку на базу данных. Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии. Возможно, если бы мы могли получить инкрементальность, то игра и стоила бы свеч, и традиционная процедура резервного копирования имела бы право на жизнь в этом случае.

    Поняв, что процедура резервного копирования здесь нежизнеспособна, я начал поиск уже существующих решений этой проблемы. Довольно быстро обнаружилось, что такие объемы информации никто не бэкапит «в лоб». Существуют несколько подходов, которые позволяют иметь резервную копию базы данных такого объема, более или менее актуальную во времени.

    Инкрементальность


    Если база данных поддерживает инкрементальный бэкап и размер постоянных изменений в базе данных относительно невелик, то можно попробовать выполнять процедуру инкрементального резервного копирования в определенные промежутки времени. Однако этот способ подходит не всем и довольно неудобен в том плане, что этот бэкап надо постоянно «накатывать» на второй экземпляр базы данных. Тут инкрементальный бэкап играет роль скорей всего последнего средства, а инкрементальность позволяет снять лишнюю нагрузку на базу данных и бэкапить только измененные данные. Тем не менее, с рядом условий это решение имеет право на жизнь, хотя и не является самым лучшим на мой взгляд.

    Репликация


    Одно из самых распространенных решений – это репликация новых и измененных данных на одну или несколько копий базы данных. Существует множество технологий, позволяющих проводить такую репликацию, как на транзакционном уровне, так и на уровне файловой системы, она может быть как синхронной, так и асинхронной. Преимущества такой репликации состоят в том, что у вас будет практически точная копия базы данных. Механизмы отлавливания ошибок во время репликации позволяют довольно быстро и безболезненно понять их причину и, вследствие этого, быстро исправить. Самый же большой недостаток – это большая нагрузка и высокая стоимость этих технологий. Однако в отсутствии возможностей поддерживать резервную копию базы данных в актуальном состоянии с помощью других средств, репликация была и будет одним из наиболее применяемых решений для сверхбольших данных.

    «Двойной» ETL


    Как правило, перед тем, как попасть в хранилище данных, данные проходят через ETL или ELT процедуры. Сама аббревиатура ETL говорит нам, что данные перед тем, как попасть в хранилище данных соответствующим образом преобразовываются, а лишние данные отсекаются. Этот процесс можно распараллелить – т.е. сделать загрузку данных не в одно хранилище данных, а в два или несколько. Таким образом, у нас будет столько копий хранилища данных, сколько нам потребуется. Но, несмотря на это, такой подход обладает существенным недостатком – зачастую копии не идентичны, так как в процессе загрузки данных возникают ошибки и несоответствия. Не всегда понятно, какая из копий является более правильной. Может быть, какой-то бизнес и может допустить такое несоответствие, но если речь идет о финансовых компаниях, то тут такое допущение не имеет право на существование. Можно разработать сложную процедуру верификации и исправлении ошибок, но, как правило, это лишь затрудняет и замедляет весь процесс. Подводя итог этому подходу, можно сказать, что он применим в ограниченном количестве случаев.

    Как уже стало понятно, практика восстановления таких объемов с бэкапов не применяется нигде – это занимает несколько дней, а то и недель. Основной методикой восстановления функциональности в случае падения основной базы данных, является переход на работающую копию базы данных. Для поддержания актуальности этой копии применяется ряд методов, некоторые из которых я перечислил выше. Традиционные подходы к резервному копированию, заключающиеся в сохранении копии базы данных и восстановлении с неё в случае отказа не работают с базами данных сверхбольших объемов – за примерами далеко ходить не надо. Суммируя всё вышесказанное, хочется поставить запятую в заголовке на правильное место – backup делать нельзя, работать без него.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 14

      +4
      Хм, странная база, которая не поддерживает инкрементальный бэкап, но поддерживает объемы в 20ТБ.

      Мож тут снеэпшоты помогут, но поскольку непонятно, что за зверь, да еще такой странной породы — то и советовать-то по сути нечего.
        +3
        По своему опыту администрирования oracle >20Тб могу сказать, что самый лучший вариант бэкапа — split mirror на уровне дисковых массивов (HP,Hitachi...).
        Копия синхронизируется с основной БД с использованием внутренних механизмов массивов с минимальной нагрузкой на БД. Далее выполняется begin backup для online бэкапа или shutdown для холодного на БД и split копии на массиве.
        При необходимости восстановления можно подняться с копии (что не очень хорошо, т.к теряется бэкап) либо выполнить обратную синхронизацию с копии на основные группы и затем подняться.
        В такой конфигурации бэкап и восстановление укладываются в несколько минут.
        Из минусов — при online бэкапе не должен идти ASM rebalance и для datafiles весьма желателен autoextend off. И еще очевидный минус — дисков надо много :)
          0
          Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии.

          А к чему такая дикая секретность? Не проще сказать, типа MySQL, версия 3.21...???
            +2
            Секретности тут нет — это был EMC Greenplum в версии 4.2.1. Инкрементального бэкапа у них нет, они обещают его сделать в следующем году. Бизнес не может ждать до следующего года и поэтому пришлось выбрать другой метод
            0
            Понятно, что зеркало спасает от аппаратного сбоя, но если данные испорчены программно (неудачное изменение структуры или ошибочный запрос, который обнулил все счета клиентов), то тут лучше иметь копию, в которую эти изменения не попали.
            Может быть, стоит зеркало нагружать (инкрементальными) бэкапами?
              0
              Да, мы тоже думали об этом и решили, что вообще без бэкапа существовать невозможно, так как может произойти такая ситуация, когда, действительно, данные могут быть испорчены программно и необходимо откатится назад во времени. Но по двум причинам:
              1. большой объем
              2. это хранилище данных, т.е. не операционная база данных
              решили делать их достаточно редко. Также эти бэкапы восстанавливаются достаточно долго, бизнес не может ждать несколько дней и нужен метод, который позволил бы в случае аппаратного сбоя быстро перейти на зеркало.
              +1
              Как уже заметили в комментариях, резервные копии(backups) нужны не только и не столько для восстановления после сбоя системы(HW), сколько для восстановления после человеческих ошибок или преднамеренных действий. Восстановить данные которые были испорчены «по всем правилам». От потери железа спасает replication/mirroring, желательно на сильно удаленный (200км) дисковый массив или БД. То есть жить без бэкапов можно, но «ленты» в сейфе спасают от большого количества проблем. Обычно в высоко нагруженных системах используют схему. Primary storage --> replication --> Secondary storage --> backup --> backup hw. Для OLAP систем это точно работает. Secondary storage нагружается только в момент загрузки данных и пока идет обработка основных данных на primary мы делаем backup c secondary.
                0
                Вы меня опередили.
                Действительно, это будет самое верное решение снимать копию со второго data storage.
                Обычно эти data storage сами умеют делать snapshot данных, причем очень быстро.
                По крайне мере у нас с hp 2000 проблем нету.
                  0
                  Автор пишет про GreenPlum, это shared nothing MPP система, нет никакого общего стореджа который можно реплицировать\снепшотить.

                  20ТБ серьезные объемы, что за организация если не секрет?
                    0
                    Да, действительно, общего стореджа нет (как это понимается в Oracle), но можно использовать единый дисковый массив, есть и табличка с информацией, где что лежит, так что варианты с replication/mirroring есть.

                    Пока официального пресс-релиза не было и я не могу разглашать имя организации. Могу сказать, что это один из банков.
                      0
                      Да, replication\mirroring возможен, это так.

                      Учитывая что Банк я понял где это :)
                  0
                  Хотя, можно делать snaps на втором массиве, если совсем никак сделать бэкапы.
                    0
                    Ваша беда никак не даёт мне покоя. EMC предлагает два основных решения для бэкапа Гринплама — Data Domain и VNX. Вы смотрели вайт-пэйперы об этом?
                      0
                      Да, смотрели. Решения хорошие, за одним исключением — стоят дорого. По сравнению с ними NFS шара стоит копейки. И даже ddboost, и data deduplication не оправдывает такой стоимости — за такие деньги можно купить кучу дисков и использовать их. Хотя, повторюсь, решения хорошие и на них можно построить отличную схему резервного копирования, если использовать DD Replicator.

                    Only users with full accounts can post comments. Log in, please.