Т.е. выбирать PostgreSQL за то, что он более идеально спроектирован чем MySQL - чистой воды религия.

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

ну вот возможно мы приползём в этот чатик - нам нужен постгрес для одного проекта.

какой кстати брать ?-)

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

Ширина и богатость инструментов очень спорный плюс. Я тут полносью согласен с Томпсоном, Керниганом, Ритчи, Пайком и компанией. В перспективе эти глубины и богатость отключают мозг. При достаточно высоком пороге вхождения. Так что это немного сомнительное преимущество. А вот реплика - нет. Она реальна. Её нельзя игнорить. И бэкап реален. Его тоже нельзя игнорить.

Ширина и богатость инструментов очень спорный плюс. Я тут полносью согласен с Томпсоном, Керниганом, Ритчи, Пайком и компанией. В перспективе эти глубины и богатость отключают мозг. При достаточно высоком пороге вхождения. Так что это немного сомнительное преимущество. А вот реплика - нет. Она реальна. Её нельзя игнорить. И бэкап реален. Его тоже нельзя игнорить.

Мозг можно не отключать, а загрузить другими интересными задачами, пока рутинные задачи уже решены на уровне бд

какой кстати брать ?-)

Бери наш postgres pro ?

Кстати о бэкапах. Есть какая-нибудь методичка "postgres лайв бэкап для чайников"? Главное, чтобы там был описан закат обратно

Мозг можно не отключать, а загрузить другими интересными задачами, пока рутинные задачи уже решены на уровне бд

Это не важно. Перекладывать задачи на БД вещь опасная. И соответственно спорная. А реплика и бэкап - нет

Чем она опасная?

А реплику перекладывать на БД а не делать вручную не опасно?

Кстати о бэкапах. Есть какая-нибудь методичка "postgres лайв бэкап для чайников"? Главное, чтобы там был описан закат обратно

http://www.postgresql.org/docs/9.5/static/continuous-archiving.html так вот же, разве не оно?

http://www.postgresql.org/docs/9.5/static/continuous-archiving.html так вот же, разве не оно?

у меня проблемы с пониманием штатной документации. от 'test ! -f /mnt/server/archivedir/%f... у меня вытекают мозги через глаза. Я конечно разберусь, но в 2016 году-то навернео есть какие-нибудь нормальные штатные способы в один шаг?

dba тоже хотят кушать

Phil это штатный unix way в чем проблема то ?

Phil это штатный unix way в чем проблема то ?

да не, не в строке конечно. а в общем стиле документации. реально это крайне плохо, когда половину надо догадываться, половину гуглить, а громадный лист ни о чём повествует нам о командах unix. вот так просто с каждой главой. когда уже понял - вроде и ок.

хрен с ним. просто как-то много воды реально.

мне нужна реплика и хочу попробовать jsonb. переживу

Фил, а ты мог бы показать образец хорошей, на твой взгляд, документации для аналогичного продукта?

а то я все никак не могу понять твоего постоянного недовольства этой частью

там должны быть скриншеты с красными стрелачками в стиле "Next->Next->OK"?

там должны быть скриншеты с красными стрелачками в стиле "Next->Next->OK"?

нет. как раз нет. а вот например прямо в месте про бэкап намес низкоуровнего объяснения WAL и скринштов :) 24.3.1 - вот это зачем конкретно в этом месте в этом виде в таком объеме? прочитал всю простыню про архивирование, половину можно выкинуть, а когда он это делает я вообще не понял - придётся гуглить. и тут я вспомнил, что я зашёл про бэкап почитать. "аналогичные продукты" это mysql что ли? есть ещё какие-то? да, у MySQL есть явные пробелы в описании каких-то параметров, но организация среднем намного лучше. вода вынесена в отдельные параграфы, в описании обычно есть сразу примеры (не всегда идеальные), которые рассчитаны на понимание общего принципа, сразу данны ссылки на "как посмотреть", почти всегда первая часть - описание общего принципа

А кстати документация доступна где то в виде исходников? Чтобы можно было для себя ее дополнить

Мне иногда не хватает примеров

А в чем там низкоуровневость WAL? Там вроде по делу поясняется, что без настройки нормальной архивации WAL говорить о нормальном бэкапе и тем более восстановлении не приходится.

А в чем там низкоуровневость WAL? Там вроде по делу поясняется, что без настройки нормальной архивации WAL говорить о нормальном бэкапе и тем более восстановлении не приходится.

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

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

надо наверное вчитаться, но при первом прочтении пропустил

Ну в общем тебе нужна не документация, а quickstart-ы

типа невникая повторил и оно вроде как работает

и считаем, что разобрались с backup-ом и восстановлением

а когда прижмет, тогда и будем вдумываться (правда уже может быть поздно к этому моменту)

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

Бекап без восстановления - ничто

все так

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

бэкап/восстановление

но не понимать что и как работает внутри

Есть, кстати способ автоматически восстановить и проверить бекап?

и это в процессе эксплуатации может привести к фатальным последствиям

а нет какого-то готового оркестратора, который ко всему этому даст более простой интерфейс?

barman

и еще ряд подобных

вот даже для мускля уже готовые инсталляторы много-мастер появляются с автоматизацией всего

не, не бекап, а пообще

http://www.pgbarman.org/

не понял?

а чего в частности?

чтобы написать, что вот у меня три сервера, сделай мне тут мультимастер, с логами на столько-то гигабайт, с бекапом вот туда

и так же в случае чего - запустить вот это, бекапы вот там

парни вы либо выполняете роль DBA и это ваш хлеб (часть его), либо вы чистые разработчики и хлеб ДБА кушают другие

в современном мире роли смешаны

базовые вещи должны быть простыми и не требовать дба

это не базовые вещи

а то можно утрировать и довести до «или на кнопочки калькулятора нажимаем, или зовем программиста на ассемблере»

когда надо затюнить конфиг, написать сложные хранимки, прооптимизировать запросы и оптимально нормализовать/денормализовать - вот тогда зовем ДБА

когда надо как-то относительно оптимально запустится - должно быть готовое решение, а не дорогой дба (который не только дорогой, но и с большим латенси)

типа невникая повторил и оно вроде как работает

если в бэкап надо вдумываться - это похороны бэкапа. я вполне конкретно прямо на примере пояснил что не так. могу сделать копи-паст. там немного не так

интересный постулат...

оставьте pg_backups и успокойтесь в таком случае

он весьма простю.

интересный постулат...

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

это про бэкапы в постгрес щас? там де одну команду толкнуть или в чем тонкость и какой квик старт нужен

вот именно таковым он в pgsql и является

Phil есть штатная тулза для бекапа, что мешает ее по крону использовать ?

если вас не интересует PITR, то к чему танцы с бубном ?

это про бэкапы в постгрес щас? там де одну команду толкнуть или в чем тонкость и какой квик старт нужен

открываю доку - она у меня 7 экранов занимает. читаю и картины нет в голове. не знаю ни про какую команду пока

кстати да, для чего вы делаете PITR? какой у вас целевой RTO и RPO?

если вас не интересует PITR, то к чему танцы с бубном ?

PITR это что, где почитать?

с этого вроде как документация начинается раздел : 24.3. Continuous Archiving and Point-in-Time Recovery (PITR)

т.е. ты ниразу не прочел эти 7 экранов полностью от начала до конца

Phil есть штатная тулза для бекапа, что мешает ее по крону использовать ?

где в доке про штатну тулзу? ну т.е. спич о доке был. опять я простейшие вещи выгугливаю и выковыриваю в чатике. это не дока

у тебя в голове каша и ты считаешь, что в этом виновата документация?

т.е. ты ниразу не прочел эти 7 экранов полностью от начала до конца

нет, я просто не сложил эти буквы

http://www.postgresql.org/docs/current/static/app-pgbasebackup.html

открываю доку - она у меня 7 экранов занимает. читаю и картины нет в голове. не знаю ни про какую команду пока

pg_dump -Fc имя_базы > имя_файла

у тебя в голове каша и ты считаешь, что в этом виновата документация?

отчасти да. отчасти конечно моя голова.

pg_dump -Fc имя_базы > имя_файла

плохая не смешная шутка

тут понаписали, я не все успел прочитать что нужно

простой бекап хочет человек

погоди, почему pg_dump плох?

он хорошо делает свою часть работы

если нужен логический бэкап (что в случае разработчика наиболее вероятно), то почему бы и нет?

простой бекап хочет человек

а чем pg_dump тогда не устраивает

а чем pg_dump тогда не устраивает

Сложно

одну команду запустить сложно)

походу это уже тролинг

есть подозрение что Phil виндузятник

=)

Вроде как 99% проектов на постгресе этого достаточно ж

и чистой воды разработчик

в этом лучае не надо лезть на поляну ДБА, и отдать проблемы бэкапов и репликаций соответсвующим спецам

кстати для меня было удивлением что pg_dump делает консистентный дам ( в виде sql значит тоже должен) " Оно создаёт согласованные копии, в том числе и на работающих базах данных. pg_dump не блокирует других пользователей базы, ни на чтение, ни на запись."

это в отличие от expdp ораклового))

MVCC

exp оракловый тож можно было в одну транзакцию попытаться запихнуть

только следи за UNDO TS

c exp не знаю), а expdp наврено не может?

я начинал с 8-9-10

на 10 уже заканчивал