Если я правильно понимаю, то цепочки трогать действительно нельзя, но файлы журналов транзакций можно удалить.
--retention-redundancy=7 Specifies the number of full backup copies to keep in the data directory.
Тут всё понятно, сколько полных копий храним для возможности восстановления в случае сбоя.
--retention-window=7 Number of days of recoverability.
Примерно то же самое, но задаётся в днях.
--wal-depth=24 Number of latest valid backups on every timeline that must retain the ability to perform PITR.
А вот это не просто восстановление, а Point In Time Recovery. Определяет политику хранения файлов WAL.
Первые два параметра не говорят ничего про WAL, а лишь закрепляют бэкапы. Я могу восстановиться дискретно на момент времени, когда любой из этих бэкапов был снят (зависит от частоты снятия бэкапов).
А третий параметр касается как файлов WAL, так и связанных с ними бэкапов, и позволяет восстановиться на любой момент времени внутри этого диапазона (до милисекунд или txid).
Вывод слишком длинный, не влезает в коммент. Вот гугло-документ с текстом.
По идее инкрементальные копии, не требуемые для PITR, должны автоматически объединяться с полными родительскими. Но этого также не происходит (--merge-expired).
Тут, возможно, дело в уровне владения английским языком. Не у всех пользователей он достаточен для комфортного чтения манов, поэтому они предпочитают гуглить и продираться сквозь кучи мусорных статеек.
Спасибо за отличный пост, Александр!
Я перевёл staging кластер на pg_probackup (с wal-g), всё работает классно, мне очень нравится. Один нюанс не очень понятен.
Я хочу иметь WAL для PITR за послендие 24 часа, и я настроил "--wal-depth=24", т.к. делаю инкрементальные бэкапы каждый час. Прошло несколько дней, но старые логи так и не удаляются. В документации сказано, что этот параметр определяет "Количество резервных копий на каждой линии времени, которое должно сохраняться для обеспечения возможности восстановления PITR." Но не сказано каких именно копий. Любых вообще или только полных?
Вот мой сетап:
полный бэкап (FULL) один раз в сутки;
инкрементальные бэкапы (PAGE) каждый час, для снижения RTO;
WAL пишется синхронно через потоковый протокол утилитой pg_receivewal;
полные копии хранятся 7 дней, а файлы небходимые для PITR хранятся 24 часа;
старые инкрементальные бэкапы объединяются с родительской полной копией.
Я точно так же использую кастомную функцию вывода отладочной информации, и контролирую её поведение при помощи set_config() для текущей сесии.
Пока не слышал, чтобы были планы на дебагер в PostgreSQL.
Код проекта PLDebugger хостится на git.postgresql.org, то есть это расширение официально принято сообществом. Но если посмотреть на лог коммитов, то приходит понимание что это никому особо не нужно. И нет поддержки в IDE. Нет и не будет, потому что реально никто и не просит (см. например тут, тут, или тут и т.д.).
Вообще-то отличается, и довольно сильно. Это позволяет не прерывать поток исполнения, подсматривать значения переменных, вычислять выражения (если вам вдруг это понадобилось, но вы заранее не предусмотрели это в коде). А динамические языки еще и разрешают перескакивать через строчки кода и изменять значения переменных прямо на лету. Только не говорите мне что не знаете как работать с отладчиком :-)
Но без этого вполне можно жить, я согласен. И я сам, как уже сказал выше, отказался от этой идеи из-за кривой реализации, и вернулся к "raise notice" (но уж точно не "raise exception"). Но было бы очень круто иметь нормальный отладчик. Всё зависит от количества кода в ваших процедурах, на самом деле.
В Oracle PL/SQL код группируется в пакеты, и там есть глобальные переменные, и пакеты могут легко иметь размер больше десяти тысяч строк. Там отладка просто неоходима, и там это реализовано на высшем уровне. В Postgres всё чуть проще.
Ах да, точно, с 9-ки можно было, но там всё было нетривиально. А в 11 довели до ума, но механизм под капотом тот же, насколько я помню.
Язык отличный, это правда. Когда переходил на Постгрес после 12 лет на Оракле, то пролил много слёз. Хотя позже там нашлось много потрясающих вещей, которых нет в Оракле :-)
Разрешите пояснить вместо автора.
Есть такое расширение "pldebugger" (нужно его собрать и поставить на сервер, код тут: https://git.postgresql.org/gitweb/?p=pldebugger.git), которое позволяет ставить break-points в коде хранимых процедур. Я тоже pgadmin не использую, это просто какая-то запредельная жесть, но слышал что он умеет работать с этим расширением из коробки.
Еще его понимает DBeaver (https://github.com/dbeaver/dbeaver/wiki/PGDebugger). Я как-то раз попытался эту связку настроить и поюзать, но оно толком не работало, постоянно вылетало с ошибками.
Тут в статье ещё упоминали производительность. Вы забыли что PL/SQL легко компилируется в бинарный код, начиная кажется с 11g. Специально для выполнения сложных расчетов в процедурном коде.
В смысле он и так всегда компилируется в момент сохранения в БД (в отличие от PL/pgSQL), но в данном случае я имел в виду трансляцию в Си с последующей компиляцией.
Я не имею никакого отношения к проекту Патрони и нигде его не пиарю. Также я ни разу не упоминал что оркестрация кластера производится Кубером.
Мой вопрос бы задан с целью узнать причину велосипедостроения и планы его развития, а также рассмотреть возможность испытания вашего продукта в тестовой лабе.
Извиняюсь за "подковырочку" про вашу замечательную компанию, однако это позволило вывести вас на чистую воду. Выяснилось, что вы считаете Java языком веб-апплетов, вроде Флеша, а также считаете JavaScript его близким родственником (на основании того что оба используют синтаксис Си и имеют похожее название). Это просто эпично! Надеюсь, ваш босс этого не увидит, иначе ждите беды.
Теперь же совершенно очевидно что у вас в голове каша и следовательно от ваших поделок нужно держаться подальше. Просто стыдно не знать такие элементарные вещи. Вы даже не представляете себе какую анти-рекламу делаете этим вашей компании. Что таки подтверждает моё предположение о некоторых проблемах в системе найма и обучения сотрудников.
По разному. В случае Постгреса я обычно беру официальный образ с docker hub, и на его основе делаю свой образ, собирая из исходников всё что нужно или копируя готовые бинарики собранные сообществом. В пакетах далеко не всегда есть то, что нужно, либо оно несвежее, без последних багфиксов.
Для обновления минорной версии достаточно простого пересоздания контейнера с нового образа. Они гарантированно бинарно совместимы. Для мажорных апдейтов (типа 11->12) требуется сначала прогнать промежуточный контейнер с pg_upgrade.
Каким боком нужен контейнер? Ну просто я не хочу задумываться о том, что имеется на конкретном хосте. Это даёт мне возможность использовать совершенно идентичные окружения и для разработки, и в стейджинге, и в проде.
Гослинг разрабатывал Джаву для бытовых устройств. У Sun даже был карманный компьютер, который работал на джаве еще в 90-х годах. Но проект не взлетел. Никакой специальной ориентации на веб у этого языка не предполагалось. Если быть точным, то джава и ПХП появились одновременно в 95-м. Уже позже люди додумались до апплетов. Я прекрасно помню эти времена, т.к. я сам писал CGI скрипты ещё раньше. Это всё развивалось на моих глазах, и прошло через мои руки в продашне, и это было классное время. JavaScript же не имеет ни малейшего отношения к Java, по-моему это знают даже дети.
Мне жаль что в вашей компании так безалаберно относятся к найму сотрудников, и оттого у вас сложилось это мнение о какой-то касте ущербных "веб-разработчиков", пишущих на флеше. Зато, наверное, им можно почти ничего не платить, не так ли? Я тоже знаю многих фронтендеров, которые не особо вникают в процессы, происходящие по ту сторону HTTP запроса на сервере. Но нельзя же всех под одну гребёнку! В моей команде три PhD Computer Science (доктора наук по нашему), больше половины программеров в команде за 50 лет, с огромным опытом в каких угодно областях программирования, есть у меня и старики которые еще застали перфокарты, и есть активные контрибьюторы в ядро Linux и другие проекты, результатами труда которых вы пользуетесь каждый день. И все вместе мы сейчас работаем над сложным веб-проектом, потому что в наше время никому не интересно саппортить и обновлять софт на стороне клиента. То есть технически мы все веб-программисты.
Про контейнеры даже продолжать не охота, но уж скажу. Представьте себе, SSD тоже можно монтировать как и NFS. Не знаю как в вашей компании, а в моей можно хоть 50 ТБ SSD подключать одним кликом к виртуальным машинам.
Извините, но ваша теория параллельной вселенной для веб-разработчиков — полная лажа. При чём тут вообще Perl и PHP? Все серьезные веб приложения пишутся на серьезных языках программирования, как например Java, или её клон С#. Весь современный энтерпрайз — это веб приложения и веб сервисы. Участие в подобных проектах требует высочайшего уровня подготовки и опыта. Многопоточная обработка в отдельных сервисах, межсервисное взаимодействие, шины и очереди сообщений, секьюрити, распределенные транзакции и прочее, о чём вы, судя по всему, даже не подозреваете. Вы, похоже, застряли где-то на рубеже 90х — 00х с вашими представлениями о разработке приложений.
Насчёт контейнеров. Само собой все персистентные данные хранятся на дисках вне контейнера. Внутри контейнера интересен только код. Во время создания контейнера в его ФС монтируются любое количество внешних файлов, директорий и секретов. Грубо говоря, к примеру, каталог PGDATA, тейблспейсы, отдельно может быть каталог pg_wal, файл .pgpass и т.д. Хотите обновить версию сервера или может быть какой-то extension, нет ничего проще. Просто пересоздаём контейнер с теми же внешними точками монтирования, но уже с другим софтом внутри, указывая другой образ.
Вы так говорите, как будто веб-разработчики это второй сорт. Да, есть такие, которые делают сайты-визитки и на этом их познания в общем-то заканчиваются. Но есть и сложнейшие распределённые системы, серверная часть которых состоит из тысяч узлов и компонентов, обрабатывающих десятки и сотни тысяч запросов в секунду. Это тоже называется веб разработкой, потому что наружу торчит веб интерфейс в виде REST API. И DBA, обслуживающие эти веб-приложения, тоже неслабо напрягаются.
Насчёт запуска СУБД внутри контейнеров — ну так это же просто удобно! Я давно полностью перешёл на деплой в контейнерах, и в продакшн и для разработки, и даже дома. Собираю свои образы со всем необходимым внутри. Все расширения, все библиотеки нужных версий, все утилиты и т.д. И мне в принципе плевать что за дистрибутив, какие пакеты и т.п. установлены на хосте, потому что я всё тащу с собой внутри контейнеров. А оверхед практически нулевой. Ну это дело вкуса, конечно. Мне понравилось и я не хочу возвращаться обратно.
Спасибо за пост, очень интересно!
А вы не смотрели в сторону Patroni? Это популярное open source решение, основанное на той же идее кворума с использованием DCS (etcd, consul и т.п.). Успешно применяется в продакшн. Здесь на Хабре было много статей про этот проект. Я не рекламирую, просто интересно чем он не подошёл именно вам.
Семён Семёныч! (facepalm) :-)
Про консистентность я и позабыл, действительно WAL файлы в архиве с дырами.
Спасибо вам огромное за помощь!
Если я правильно понимаю, то цепочки трогать действительно нельзя, но файлы журналов транзакций можно удалить.
--retention-redundancy=7
Specifies the number of full backup copies to keep in the data directory.
Тут всё понятно, сколько полных копий храним для возможности восстановления в случае сбоя.
--retention-window=7
Number of days of recoverability.
Примерно то же самое, но задаётся в днях.
--wal-depth=24
Number of latest valid backups on every timeline that must retain the ability to perform PITR.
А вот это не просто восстановление, а Point In Time Recovery. Определяет политику хранения файлов WAL.
Первые два параметра не говорят ничего про WAL, а лишь закрепляют бэкапы. Я могу восстановиться дискретно на момент времени, когда любой из этих бэкапов был снят (зависит от частоты снятия бэкапов).
А третий параметр касается как файлов WAL, так и связанных с ними бэкапов, и позволяет восстановиться на любой момент времени внутри этого диапазона (до милисекунд или txid).
Да вот то то и оно, что непонятно почему он считает что нечего удалять.
Последние 24 бэкапа (любые?) нужны для PITR, остальное можно удалять.
Добавил в конец документа
Вывод слишком длинный, не влезает в коммент. Вот гугло-документ с текстом.
По идее инкрементальные копии, не требуемые для PITR, должны автоматически объединяться с полными родительскими. Но этого также не происходит (--merge-expired).
Ключик конечно есть, но почему-то не срабатывает.
Тут, возможно, дело в уровне владения английским языком. Не у всех пользователей он достаточен для комфортного чтения манов, поэтому они предпочитают гуглить и продираться сквозь кучи мусорных статеек.
Спасибо за отличный пост, Александр!
Я перевёл staging кластер на pg_probackup (с wal-g), всё работает классно, мне очень нравится. Один нюанс не очень понятен.
Я хочу иметь WAL для PITR за послендие 24 часа, и я настроил "--wal-depth=24", т.к. делаю инкрементальные бэкапы каждый час. Прошло несколько дней, но старые логи так и не удаляются. В документации сказано, что этот параметр определяет "Количество резервных копий на каждой линии времени, которое должно сохраняться для обеспечения возможности восстановления PITR." Но не сказано каких именно копий. Любых вообще или только полных?
Вот мой сетап:
Это что ещё за "No lock" в Postgres выдумали? Уровень изоляции "Read uncommitted" там не поддерживается.
Про эскалацию блокировок на уровень таблицы тоже очень расплывчато написано. Будто бы так делают все РСУБД. Это неправда.
Я точно так же использую кастомную функцию вывода отладочной информации, и контролирую её поведение при помощи set_config() для текущей сесии.
Код проекта PLDebugger хостится на git.postgresql.org, то есть это расширение официально принято сообществом. Но если посмотреть на лог коммитов, то приходит понимание что это никому особо не нужно. И нет поддержки в IDE. Нет и не будет, потому что реально никто и не просит (см. например тут, тут, или тут и т.д.).
Вообще-то отличается, и довольно сильно. Это позволяет не прерывать поток исполнения, подсматривать значения переменных, вычислять выражения (если вам вдруг это понадобилось, но вы заранее не предусмотрели это в коде). А динамические языки еще и разрешают перескакивать через строчки кода и изменять значения переменных прямо на лету. Только не говорите мне что не знаете как работать с отладчиком :-)
Но без этого вполне можно жить, я согласен. И я сам, как уже сказал выше, отказался от этой идеи из-за кривой реализации, и вернулся к "raise notice" (но уж точно не "raise exception"). Но было бы очень круто иметь нормальный отладчик. Всё зависит от количества кода в ваших процедурах, на самом деле.
В Oracle PL/SQL код группируется в пакеты, и там есть глобальные переменные, и пакеты могут легко иметь размер больше десяти тысяч строк. Там отладка просто неоходима, и там это реализовано на высшем уровне. В Postgres всё чуть проще.
Ах да, точно, с 9-ки можно было, но там всё было нетривиально. А в 11 довели до ума, но механизм под капотом тот же, насколько я помню.
Язык отличный, это правда. Когда переходил на Постгрес после 12 лет на Оракле, то пролил много слёз. Хотя позже там нашлось много потрясающих вещей, которых нет в Оракле :-)
Разрешите пояснить вместо автора.
Есть такое расширение "pldebugger" (нужно его собрать и поставить на сервер, код тут: https://git.postgresql.org/gitweb/?p=pldebugger.git), которое позволяет ставить break-points в коде хранимых процедур. Я тоже pgadmin не использую, это просто какая-то запредельная жесть, но слышал что он умеет работать с этим расширением из коробки.
Еще его понимает DBeaver (https://github.com/dbeaver/dbeaver/wiki/PGDebugger). Я как-то раз попытался эту связку настроить и поюзать, но оно толком не работало, постоянно вылетало с ошибками.
Тут в статье ещё упоминали производительность. Вы забыли что PL/SQL легко компилируется в бинарный код, начиная кажется с 11g. Специально для выполнения сложных расчетов в процедурном коде.
В смысле он и так всегда компилируется в момент сохранения в БД (в отличие от PL/pgSQL), но в данном случае я имел в виду трансляцию в Си с последующей компиляцией.
Я не имею никакого отношения к проекту Патрони и нигде его не пиарю. Также я ни разу не упоминал что оркестрация кластера производится Кубером.
Мой вопрос бы задан с целью узнать причину велосипедостроения и планы его развития, а также рассмотреть возможность испытания вашего продукта в тестовой лабе.
Извиняюсь за "подковырочку" про вашу замечательную компанию, однако это позволило вывести вас на чистую воду. Выяснилось, что вы считаете Java языком веб-апплетов, вроде Флеша, а также считаете JavaScript его близким родственником (на основании того что оба используют синтаксис Си и имеют похожее название). Это просто эпично! Надеюсь, ваш босс этого не увидит, иначе ждите беды.
Теперь же совершенно очевидно что у вас в голове каша и следовательно от ваших поделок нужно держаться подальше. Просто стыдно не знать такие элементарные вещи. Вы даже не представляете себе какую анти-рекламу делаете этим вашей компании. Что таки подтверждает моё предположение о некоторых проблемах в системе найма и обучения сотрудников.
По разному. В случае Постгреса я обычно беру официальный образ с docker hub, и на его основе делаю свой образ, собирая из исходников всё что нужно или копируя готовые бинарики собранные сообществом. В пакетах далеко не всегда есть то, что нужно, либо оно несвежее, без последних багфиксов.
Для обновления минорной версии достаточно простого пересоздания контейнера с нового образа. Они гарантированно бинарно совместимы. Для мажорных апдейтов (типа 11->12) требуется сначала прогнать промежуточный контейнер с pg_upgrade.
Каким боком нужен контейнер? Ну просто я не хочу задумываться о том, что имеется на конкретном хосте. Это даёт мне возможность использовать совершенно идентичные окружения и для разработки, и в стейджинге, и в проде.
Гослинг разрабатывал Джаву для бытовых устройств. У Sun даже был карманный компьютер, который работал на джаве еще в 90-х годах. Но проект не взлетел. Никакой специальной ориентации на веб у этого языка не предполагалось. Если быть точным, то джава и ПХП появились одновременно в 95-м. Уже позже люди додумались до апплетов. Я прекрасно помню эти времена, т.к. я сам писал CGI скрипты ещё раньше. Это всё развивалось на моих глазах, и прошло через мои руки в продашне, и это было классное время. JavaScript же не имеет ни малейшего отношения к Java, по-моему это знают даже дети.
Мне жаль что в вашей компании так безалаберно относятся к найму сотрудников, и оттого у вас сложилось это мнение о какой-то касте ущербных "веб-разработчиков", пишущих на флеше. Зато, наверное, им можно почти ничего не платить, не так ли? Я тоже знаю многих фронтендеров, которые не особо вникают в процессы, происходящие по ту сторону HTTP запроса на сервере. Но нельзя же всех под одну гребёнку! В моей команде три PhD Computer Science (доктора наук по нашему), больше половины программеров в команде за 50 лет, с огромным опытом в каких угодно областях программирования, есть у меня и старики которые еще застали перфокарты, и есть активные контрибьюторы в ядро Linux и другие проекты, результатами труда которых вы пользуетесь каждый день. И все вместе мы сейчас работаем над сложным веб-проектом, потому что в наше время никому не интересно саппортить и обновлять софт на стороне клиента. То есть технически мы все веб-программисты.
Про контейнеры даже продолжать не охота, но уж скажу. Представьте себе, SSD тоже можно монтировать как и NFS. Не знаю как в вашей компании, а в моей можно хоть 50 ТБ SSD подключать одним кликом к виртуальным машинам.
Извините, но ваша теория параллельной вселенной для веб-разработчиков — полная лажа. При чём тут вообще Perl и PHP? Все серьезные веб приложения пишутся на серьезных языках программирования, как например Java, или её клон С#. Весь современный энтерпрайз — это веб приложения и веб сервисы. Участие в подобных проектах требует высочайшего уровня подготовки и опыта. Многопоточная обработка в отдельных сервисах, межсервисное взаимодействие, шины и очереди сообщений, секьюрити, распределенные транзакции и прочее, о чём вы, судя по всему, даже не подозреваете. Вы, похоже, застряли где-то на рубеже 90х — 00х с вашими представлениями о разработке приложений.
Насчёт контейнеров. Само собой все персистентные данные хранятся на дисках вне контейнера. Внутри контейнера интересен только код. Во время создания контейнера в его ФС монтируются любое количество внешних файлов, директорий и секретов. Грубо говоря, к примеру, каталог PGDATA, тейблспейсы, отдельно может быть каталог pg_wal, файл .pgpass и т.д. Хотите обновить версию сервера или может быть какой-то extension, нет ничего проще. Просто пересоздаём контейнер с теми же внешними точками монтирования, но уже с другим софтом внутри, указывая другой образ.
Вы так говорите, как будто веб-разработчики это второй сорт. Да, есть такие, которые делают сайты-визитки и на этом их познания в общем-то заканчиваются. Но есть и сложнейшие распределённые системы, серверная часть которых состоит из тысяч узлов и компонентов, обрабатывающих десятки и сотни тысяч запросов в секунду. Это тоже называется веб разработкой, потому что наружу торчит веб интерфейс в виде REST API. И DBA, обслуживающие эти веб-приложения, тоже неслабо напрягаются.
Насчёт запуска СУБД внутри контейнеров — ну так это же просто удобно! Я давно полностью перешёл на деплой в контейнерах, и в продакшн и для разработки, и даже дома. Собираю свои образы со всем необходимым внутри. Все расширения, все библиотеки нужных версий, все утилиты и т.д. И мне в принципе плевать что за дистрибутив, какие пакеты и т.п. установлены на хосте, потому что я всё тащу с собой внутри контейнеров. А оверхед практически нулевой. Ну это дело вкуса, конечно. Мне понравилось и я не хочу возвращаться обратно.
Спасибо за пост, очень интересно!
А вы не смотрели в сторону Patroni? Это популярное open source решение, основанное на той же идее кворума с использованием DCS (etcd, consul и т.п.). Успешно применяется в продакшн. Здесь на Хабре было много статей про этот проект. Я не рекламирую, просто интересно чем он не подошёл именно вам.