Дамп огромной базы

Всем привет)
Есть база данных. База большая + с ней идет постоянная работа.
Само собой нужен бэкап на всякий пожарный.
Динамика в базе бешеная.
Пока будет идти бэкап, получается, база может сильно измениться. (а если там будут связанные меж собой таблицы. получится вообще фигня).
Сразу скажу, сейчас этап проектирования. Думаю взять PostgreSQL.

Что делать? Как бэкапить?

2 варианта, тормозить базу и бэкапить - плохой вариант

Хороший вариант:
делайте слейв сервант, его во время бэкапа лочить и сливать, после разблокировке он по логам нагонит мастер
только следить, что бы размер лога превосходит по времени время бэкапа
если есть возможность, то вообще суточный делать


Или ставьте Oracle -там все нормально

есть к sql бэкап системы - платные, стоят дорого

ArtPro, Благодарю за ответ.
Буду делать Master-Slave.

Enkvist, это когда ссылка

Ну или что у вас там за база?

frig, Postgresql.
Я уже все нашел) вообще я так понял, это админское дело. Пусть админ и разбирается, как это замутить.

А чего тогда серьезную базу не построить на чем-то более серьезном, чем Postgresql? Например, Oracle или DB2?

wertex76, я не умею с ними работать.

Цитата ("wertex76"):

А чего тогда серьезную базу не построить на чем-то более серьезном, чем Postgresql? Например, Oracle или DB2?

они равноценны в принципе, если не заниматься писаниной хранимок и т.п.
хотя если делать на оракле, то и php порой не нужен

ArtPro, Я верю в здравый смысл и прямые руки. Я точно уверен, что я сделаю шикарную вещь и на PostgreSQL.
Может быть Oracle лучше. Может быть. Но я буду стараться на PostgreSQL.

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

akkort, интересная идея. буду думать.

Цитата ("akkort"):

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

а ничего, что скорость работы диска на порядки меньше, чем памяти и лога sql
к тому же человеку не хочется вырубать базу для бэкапа, а Вы предлагаете гемморой непонятный и все так же выключать.
конфиг мастер-слейв или 2 слейва - это самый правильный.
причем если мы делаем бэкап не версионный, а просто для обеспечения безопасности, то ставить мастер-слейв по разным серверам и бэкапить не надо
если дохнет мастер, то слейв делаем мастером и все работает дальше мастером, а в это время чиним мастер, прописываем слейвом и при запуске он прочитает бинлог нового мастера и все будет опять синхронно.
можно все сделать скриптом

ArtPro, дело говорит. Как у белых людей.
А если надо так чтобы костылик какой-то подешевле да попроще и оно все "само" работало, то от такой системы может быть даже вред, а не польза.

Цитата ("Enkvist"):

ArtPro, Благодарю за ответ.
Буду делать Master-Slave

Правильно, это лучший вариант.

Цитата ("Enkvist"):

Я уже все нашел) вообще я так понял, это админское дело. Пусть админ и разбирается, как это замутить.

Админ — это тот же юзер, только опытный, и с админскими правами. Не более чем. Соответственно, организация бакапов базы лежит на разработчике (в данном случае на DBA), а админ впоследствии будет просто следовать инструкциям (как правильно делать бакап, или как восстанавливать после сбоя), которые ему напишут разработчики. И это правильно, так как админ может не знать нюансов проекта.

Иными словами, настроить бакап проекта — это дело не админов, а разработчиков проекта. Это должно быть описано в ТЗ, должно быть частью работ по разработке проекта, и должно быть протестировано. Соответственно, на это должен быть выделен бюджет и человеко-часы. А админ уже потом будет работать по инструкции.

Цитата ("tvv"):

Иными словами, настроить бакап проекта — это дело не админов, а разработчиков проекта.

ой не факт. как доп услуга - да.
забота о сохранности данных, железе и т.п. - это доп. услуги.
т.е. если архитектура не подразумевает какой нить sqlproxy а за ним 3 мастера и к ним по 2 слейва и надо уметь читать напрямую со слейвов, то и.. разрабу глубоко наплевать на чем, как и где стоит база

Я вот тоже считаю, что пусть админ настроит все дела. Я тут каким боком? Может еще ядро сервера оптимизировать?) тоже надо ведь)) я оптимизирую. потом напишу инструкцию, где какие галочки поставить.. а потом вышлю админу и он это сделает)))
Я и так полез узнавать как это все делается , и какие есть решения... а по идее это все админ должен знать..

неее. Настройка ПО дело админа - я это ПО только пользую.

Цитата ("ArtPro"):

а ничего, что скорость работы диска на порядки меньше, чем памяти и лога sql

Это миф. Можете проверить - делаете скрипт на 1млн insert'ов, а следом скрипт на запись в файл 1млн строк этими insert'ами.
Вы будете неприятно удивлены. Если там update на индексированную базу, то разница будет еще более заметна.

Цитата ("ArtPro"):

к тому же человеку не хочется вырубать базу для бэкапа, а Вы предлагаете гемморой непонятный и все так же выключать.

Выключать при желании, если проблем нет - пусть лог хоть до 100 гиг растет, он пассивно хранится и оперативки и процессора не ииспользует.

Цитата ("ArtPro"):

конфиг мастер-слейв или 2 слейва - это самый правильный.
причем если мы делаем бэкап не версионный, а просто для обеспечения безопасности, то ставить мастер-слейв по разным серверам и бэкапить не надо
если дохнет мастер, то слейв делаем мастером и все работает дальше мастером, а в это время чиним мастер, прописываем слейвом и при запуске он прочитает бинлог нового мастера и все будет опять синхронно.
можно все сделать скриптом

В пределах одной машины делать не имеет смысла, а на двух машинах - удорожание архитектуры. Если ставить на одну машину и раскидывать базы по разным физическим дискам, то удваиваем нагрузку на процессор.

Цитата ("akkort"):

В пределах одной машины делать не имеет смысла

делать бэкапы в пределах одной машины тоже не имеет смысла

Цитата ("akkort"):

Если ставить на одну машину и раскидывать базы по разным физическим дискам, то удваиваем нагрузку на процессор.

если есть 2 винта, значит делает raid

Цитата ("akkort"):

пусть лог хоть до 100 гиг растет, он пассивно хранится и оперативки и процессора не ииспользует.

он использует диск, а так как лог будет писаться короткими записями/порциями, то скорость записи = IOP диска, для серверного sata без рейда - это около 300iop (К примеру, HDD со скоростью вращения 15000 RPM сможет обеспечить не более 350 IOPS.)
и так.. не считая прочих операций и файловых журналов мы имеем не более 350 записей в секунду.
лажа какая то.... для блога на wp3 - это около 20 просмотров страниц, и это с учетом, что php у нас святым духом появляются, графики нет и ничего не инклудим.

Цитата ("akkort"):

Это миф. Можете проверить - делаете скрипт на 1млн insert'ов, а следом скрипт на запись в файл 1млн строк этими insert'ами.
Вы будете неприятно удивлены. Если там update на индексированную базу, то разница будет еще более заметна.

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