Pull to refresh

Comments 24

Благодарю, информация оказалась полезной, буквально за 5 минут вспомнил, что необходимо проверить в паре проектов.
Особенное спасибо за pg_clog, и порадовали, и предупредили
У меня куча мелких проектов и Я настроил когда-то себе pg_dumpall. На выходе он, как и pg_dump — выдает sql. Я правильно понял, что я не смогу восстановить базу, если «когда-нибудь удалю файлы из pg_clog»?
Если нет резервных копий, то да. Невозможно вернуть ее в неконфликтное состояние. Если есть бекапы, то pg_restore или psql
Понятно. А Я уж перепугался, что мои sql-бэкапы не сработают :)
Он (pg_dumpall), кстати, может и в нативном формате отдавать. В связи с чем вопрос: «А почему SQL?»
Я не имею дела с большими объемами и из соображений совместимости выбрал SQL. У меня дамп всех баз делается меньше минуты :)
А чем был обусловлен выбор именно PostgreSQL для этих проектов? Просто праздный интерес.
Если вопрос: «почем не MySQL»? То ответ такой: с этой СУБД мы больше работали в последние годы и она нам лучше знакома. А так для части проектов мы вообще SQLite используем.
На самом деле, я как раз думал, а почему бы не использовать SQLite для таких маленьких БД :)
Кстати, возник вопрос, и сразу прошу прощения, не покопался самостоятельно и глубоко. (да и не совсем в тему статьи)
Настроить специфическое логирование в PostgreSQL (SQL запросы отдельного пользователя или к определённой таблице в отдельный файл) тяжко, или возможно, «скуривая по ходу дела мануал»?
Врядли такое возможно с наскоку. Но можно, например, вести лог в CSV-формате, а потом импортировать его в базу и там уже крутить-вертеть. Об этом тут в конце написано. В любом случае будет быстрее, чем вешать триггеры на таблицы, по моему скромному.
Один из самых полезных топиков за последнее время на хабре, где нет политики, лулзов и прочего треша. Спасибо!
А я вообще обычно переношу логи операций Посгреса из каталога самой базы, исходя из того, что логи операций скорее относятся более к содержимому /var/log, чем к данным и состоянию инстанса.Делаю примерно так в postgresql.conf:
log_directory = '/var/log/postgres'

А, вообще, спасибо за топик! Полезно разложил по полочкам что есть какие логи.
$PGDATA/pg_xlog — это место, где PostgreSQL хранит журнал транзакций. Этот набор бинарных файлов, с названиями вида '00000001000000000000008E', которые содержат образы данных последних транзакций. Эти журналы также используются при бинарной репликации.
Можно вопрос? Только начал изучать pg, тем более на работе как раз делаем трансферы с мускула на слоника, ну и переходим на postgres. Как понимаю, такое большое количество чисел обусловлено предназначением каждой для какой либо операции? Скажем, в Оракле для хранения используется примерно такой способ, несколько чисел для самой инфы, потом блок для его местонахождения и посл. индексирования и связи с блоком обработки, ну и еще добавляются заголовки всякого рода служебной информации. Тут примерно так же? Что, к примеру, означает E в конце названия бинарника? Спасибо заранее за ответ.
Если честно, понятия не имею, но! У Постгреса шикарный исходный код. И я думаю, что при надобности можно найти ответ там. Врядли это описано в документации.
Спасибо, в принципе как обычно, гугл, скилопедия, педивикия и пр. интересные книжечки в помощь =) Как говорится, если не ты, то кто же :)
Это нумерация сегментов бинарного лога(WAL). Она идёт в 16тиричном формате. Первая единица — так называемый timeline, остальное — счётчик. Если, вы, например, используя штатную репликацию потеряете мастер, а потом решите перевести реплику в stand-alone, то после выполнения операции, timeline увеличится на единицу, а остальная часть счётчика сбросится. Так же в этом случае вы увидите history-файл, который будет указывать, с какой позиции произошел переход на новую нумерацию.

А вообще — обратите внимание на официальный мануал на сайте PostgreSQL — он хоть и на английском, но интуитивно понятен. :)
Only those users with full accounts are able to leave comments. Log in, please.