Comments 12
UFO just landed and posted this here
Хм, мне всегда казалось, что единственный более менее адекватный вариант резервирования базы данных — это асинхронная реплика. В остальных случаях, в случае физического отказа дисков вы потеряете слишком много данных. Правда это не отменяет регламентного бэкапа на случай логической потери данных (случайно запрос что-то не то сделал). Но тогда восстановление идет уже в ручном режиме тем, кто поддерживает ПО (так как администратор не знает структуры базы и что нужно для ее целостности).
Репликация — это всего лишь инструмент для создания двух (или более) запоротых баз данных из одной, с небольшой задержкой в случае асинхронной репликации.
Репликация помогает при физическом отказе дисков. А отказывают обычно только на одном (если там они не висят на одних и тех же дисках в одной и той же хранилке). Обычная копия нужна как раз, чтобы восстанавливать поврежденные данные. Но тогда обычно идет восстановление не всей базы, а конкретных таблиц.
Репликация бывает с снепшотами ;-), например в реализации VMware VSphere
Тут следует учитывать два момента: асинхронная реплика — это тоже потеря данных, и служба эксплуатации может просто не успеть переключится на реплику. Например, если реплика идет очень часто, раз в 5-15 минут. Но переключение на реплику всегда быстрее и потому ее неплохо иметь так же. Восстановление же, верно, идет в ручном режиме. Резервные копии так же можно делать достаточно часто. Это зависит от метода копирования и конкретной СУБД. Я скорее к тому, что нужно учитывать максимум вариантов сбоя и прорабатывать методы их устранения. Идеально, если разработчик задумается об этом на этапе создания своего продукта. Вполне прекрасно, если это требование будет внесено в ТЗ на разработку.
Это очень поверхностный подход. А нужен комплексный.
В зависимости от базы, ее размера, критичности и стоимости данных выбирается свой инструмент. В том числе есть решения класса Continuos Data Protection, которые позволяют синхронно реплицироваться и откатываться на нужный момент времени. Например, Oracle Standby с FlashBack логами.
Для очень критичных баз обычно делается так: Кластер высокой доступности в одном ЦОД, Standby в другом ЦОД, там отстающий Standby с логами (можно FlashBack).
Статья про трудности РК
В зависимости от базы, ее размера, критичности и стоимости данных выбирается свой инструмент. В том числе есть решения класса Continuos Data Protection, которые позволяют синхронно реплицироваться и откатываться на нужный момент времени. Например, Oracle Standby с FlashBack логами.
Для очень критичных баз обычно делается так: Кластер высокой доступности в одном ЦОД, Standby в другом ЦОД, там отстающий Standby с логами (можно FlashBack).
Статья про трудности РК
Не спорю. Но в жизни не так много задач, который требуют такой уровень. Если вы обрабатываете банковские транзакции то конечно. А если считаете лайки на котиков или простенькую учетную систему на 3 пользователя, то нет.
Но чаще всего достаточно асинхронной реплики и регламентных бэкапов. У меня на практике еще пока ни разу не рушились raid'ы, а из бэкапов нужно было доставать крайне редко и достаточно некритичные данные.
Но чаще всего достаточно асинхронной реплики и регламентных бэкапов. У меня на практике еще пока ни разу не рушились raid'ы, а из бэкапов нужно было доставать крайне редко и достаточно некритичные данные.
Про лайки с котиками не знаю, такие компании к нам не обращаются. Как я писал, зависит от «базы, ее размера, критичности и стоимости данных».
Автор поста писал про «суровый энтерпрайз», не думаю, что это не про котиков.
У меня на практике рушились рейды, выходили из строя оба контроллера СХД сразу, люди портили словарь базы, заливали СХД, перегревали ЦОДы, ломались процессоры, системные платы, память. И это происходит достаточно часто, если мы говорим про большие компании.
Автор поста писал про «суровый энтерпрайз», не думаю, что это не про котиков.
У меня на практике рушились рейды, выходили из строя оба контроллера СХД сразу, люди портили словарь базы, заливали СХД, перегревали ЦОДы, ломались процессоры, системные платы, память. И это происходит достаточно часто, если мы говорим про большие компании.
dump в /tmp
отличное решение
отожрём памяти и свалимся в swap
как характеризовал один мой знакомый ощущение работы на новом месте
«любительская хоккейная команда»
отличное решение
отожрём памяти и свалимся в swap
как характеризовал один мой знакомый ощущение работы на новом месте
«любительская хоккейная команда»
Sign up to leave a comment.
Немного опыта про backup & storage