За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.
Недавно перед нами была поставлена задача – разработать процедуру резервного копирования хранилища данных размером в 20 Терабайт. Используя наработанные практики резервного копирования, я попытался разработать такую процедуру и уложиться в то же время в рамки RPO (recovery point objective) и RTO (recovery time objective). Обе эти характеристики измеряются во времени и представляют собой следующее: RPO – допустимый объем возможных потерь данных, RTO – допустимое время простоя или за какое время база данных должна восстановиться. Вот тут-то и началось самое интересное – как бы я не прикидывал и не рассчитывал, но разработанная процедура резервного копирования никак не желала укладываться в эти рамки – слишком большой объем данных надо было забэкапить. В самом лучшем случае, с многочисленными оговорками и условиями база данных восстанавливалась за несколько часов, а такого бизнес себе позволить не мог. В обычной же ситуации, когда на базу данных не налагались серьезные ограничения и условия, восстановление заняло бы несколько дней. Это усугублялось тем, что невозможно «снять» бэкап за приемлемое время – это также занимало несколько дней и создавало большую нагрузку на базу данных. Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии. Возможно, если бы мы могли получить инкрементальность, то игра и стоила бы свеч, и традиционная процедура резервного копирования имела бы право на жизнь в этом случае.
Поняв, что процедура резервного копирования здесь нежизнеспособна, я начал поиск уже существующих решений этой проблемы. Довольно быстро обнаружилось, что такие объемы информации никто не бэкапит «в лоб». Существуют несколько подходов, которые позволяют иметь резервную коп��ю базы данных такого объема, более или менее актуальную во времени.
Если база данных поддерживает инкрементальный бэкап и размер постоянных изменений в базе данных относительно невелик, то можно попробовать выполнять процедуру инкрементального резервного копирования в определенные промежутки времени. Однако этот способ подходит не всем и довольно неудобен в том плане, что этот бэкап надо постоянно «накатывать» на второй экземпляр базы данных. Тут инкрементальный бэкап играет роль скорей всего последнего средства, а инкрементальность позволяет снять лишнюю нагрузку на базу данных и бэкапить только измененные данные. Тем не менее, с рядом условий это решение имеет право на жизнь, хотя и не является самым лучшим на мой взгляд.
Одно из самых распространенных решений – это репликация новых и измененных данных на одну или несколько копий базы данных. Существует множество технологий, позволяющих проводить такую репликацию, как на транзакционном уровне, так и на уровне файловой системы, она может быть как синхронной, так и асинхронной. Преимущества такой репликации состоят в том, что у вас будет практически точная копия базы данных. Механизмы отлавливания ошибок во время репликации позволяют довольно быстро и безболезненно понять их причину и, вследствие этого, быстро исправить. Самый же большой недостаток – это большая нагрузка и высокая стоимость этих технологий. Однако в отсутствии возможностей поддерживать резервную копию базы данных в актуальном состоянии с помощью других средств, репликация была и будет одним из наиболее применяемых решений для сверхбольших данных.
Как правило, перед тем, как попасть в хранилище данных, данные проходят через ETL или ELT процедуры. Сама аббревиатура ETL говорит нам, что данные перед тем, как попасть в хранилище данных соответствующим образом преобразовываются, а лишние данные отсекаются. Этот процесс можно распараллелить – т.е. сделать загрузку данных не в одно хранилище данных, а в два или несколько. Таким образом, у нас будет столько копий хранилища данных, сколько нам потребуется. Но, несмотря на это, такой подход обладает существенным недостатком – зачастую копии не идентичны, так как в процессе загрузки данных возникают ошибки и несоответствия. Не всегда понятно, какая из копий является более правильной. Может быть, какой-то бизнес и может допустить такое несоответствие, но если речь идет о финансовых компаниях, то тут такое допущение не имеет право на существование. Можно разработать сложную процедуру верификации и исправлении ошибок, но, как правило, это лишь затрудняет и замедляет весь процесс. Подводя итог этому подходу, можно сказать, что он применим в ограниченном количестве случаев.
Как уже стало понятно, практика восстановления таких объемов с бэкапов не применяется нигде – это занимает несколько дней, а то и недель. Основной методикой восстановления функциональности в случае падения основной базы данных, является переход на работающую копию базы данных. Для поддержания актуальности этой копии применяется ряд методов, некоторые из которых я перечислил выше. Традиционные подходы к резервному копированию, заключающиеся в сохранении копии базы данных и восстановлении с неё в случае отказа не работают с базами данных сверхбольших объемов – за примерами далеко ходить не надо. Суммируя всё вышесказанное, хочется поставить запятую в заголовке на правильное место – backup делать нельзя, работать без него.
Недавно перед нами была поставлена задача – разработать процедуру резервного копирования хранилища данных размером в 20 Терабайт. Используя наработанные практики резервного копирования, я попытался разработать такую процедуру и уложиться в то же время в рамки RPO (recovery point objective) и RTO (recovery time objective). Обе эти характеристики измеряются во времени и представляют собой следующее: RPO – допустимый объем возможных потерь данных, RTO – допустимое время простоя или за какое время база данных должна восстановиться. Вот тут-то и началось самое интересное – как бы я не прикидывал и не рассчитывал, но разработанная процедура резервного копирования никак не желала укладываться в эти рамки – слишком большой объем данных надо было забэкапить. В самом лучшем случае, с многочисленными оговорками и условиями база данных восстанавливалась за несколько часов, а такого бизнес себе позволить не мог. В обычной же ситуации, когда на базу данных не налагались серьезные ограничения и условия, восстановление заняло бы несколько дней. Это усугублялось тем, что невозможно «снять» бэкап за приемлемое время – это также занимало несколько дней и создавало большую нагрузку на базу данных. Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии. Возможно, если бы мы могли получить инкрементальность, то игра и стоила бы свеч, и традиционная процедура резервного копирования имела бы право на жизнь в этом случае.
Поняв, что процедура резервного копирования здесь нежизнеспособна, я начал поиск уже существующих решений этой проблемы. Довольно быстро обнаружилось, что такие объемы информации никто не бэкапит «в лоб». Существуют несколько подходов, которые позволяют иметь резервную коп��ю базы данных такого объема, более или менее актуальную во времени.
Инкрементальность
Если база данных поддерживает инкрементальный бэкап и размер постоянных изменений в базе данных относительно невелик, то можно попробовать выполнять процедуру инкрементального резервного копирования в определенные промежутки времени. Однако этот способ подходит не всем и довольно неудобен в том плане, что этот бэкап надо постоянно «накатывать» на второй экземпляр базы данных. Тут инкрементальный бэкап играет роль скорей всего последнего средства, а инкрементальность позволяет снять лишнюю нагрузку на базу данных и бэкапить только измененные данные. Тем не менее, с рядом условий это решение имеет право на жизнь, хотя и не является самым лучшим на мой взгляд.
Репликация
Одно из самых распространенных решений – это репликация новых и измененных данных на одну или несколько копий базы данных. Существует множество технологий, позволяющих проводить такую репликацию, как на транзакционном уровне, так и на уровне файловой системы, она может быть как синхронной, так и асинхронной. Преимущества такой репликации состоят в том, что у вас будет практически точная копия базы данных. Механизмы отлавливания ошибок во время репликации позволяют довольно быстро и безболезненно понять их причину и, вследствие этого, быстро исправить. Самый же большой недостаток – это большая нагрузка и высокая стоимость этих технологий. Однако в отсутствии возможностей поддерживать резервную копию базы данных в актуальном состоянии с помощью других средств, репликация была и будет одним из наиболее применяемых решений для сверхбольших данных.
«Двойной» ETL
Как правило, перед тем, как попасть в хранилище данных, данные проходят через ETL или ELT процедуры. Сама аббревиатура ETL говорит нам, что данные перед тем, как попасть в хранилище данных соответствующим образом преобразовываются, а лишние данные отсекаются. Этот процесс можно распараллелить – т.е. сделать загрузку данных не в одно хранилище данных, а в два или несколько. Таким образом, у нас будет столько копий хранилища данных, сколько нам потребуется. Но, несмотря на это, такой подход обладает существенным недостатком – зачастую копии не идентичны, так как в процессе загрузки данных возникают ошибки и несоответствия. Не всегда понятно, какая из копий является более правильной. Может быть, какой-то бизнес и может допустить такое несоответствие, но если речь идет о финансовых компаниях, то тут такое допущение не имеет право на существование. Можно разработать сложную процедуру верификации и исправлении ошибок, но, как правило, это лишь затрудняет и замедляет весь процесс. Подводя итог этому подходу, можно сказать, что он применим в ограниченном количестве случаев.
Как уже стало понятно, практика восстановления таких объемов с бэкапов не применяется нигде – это занимает несколько дней, а то и недель. Основной методикой восстановления функциональности в случае падения основной базы данных, является переход на работающую копию базы данных. Для поддержания актуальности этой копии применяется ряд методов, некоторые из которых я перечислил выше. Традиционные подходы к резервному копированию, заключающиеся в сохранении копии базы данных и восстановлении с неё в случае отказа не работают с базами данных сверхбольших объемов – за примерами далеко ходить не надо. Суммируя всё вышесказанное, хочется поставить запятую в заголовке на правильное место – backup делать нельзя, работать без него.
