pgbackrest не умеет в S3? Это очень дерзкое и весьма далёкое от реальности заявление: https://habr.com/ru/articles/820349/ А оригинал в коммуне ЖЖ я делал в 2019-м, и уже тогда pgbackrest умел в S3. Как вы выглядите без тщательной проработки вопроса, публикуя столь недостоверную информацию, решайте сами.
Пункт 3 это по факту создание хардлинков и занимает несколько секунд.
Нет. Надо тестировать. Потому что, помимо хардлинков создаётся из старой версии и накатывается на новую полный дамп схемы. А тут возможны варианты, особенно при наличии large objects (https://postgrespro.ru/docs/postgresql/17/largeobjects), которые живут в системном каталоге, соответственно, попадают в упомянутый дамп схемы. Да, наличие подобных объектов не вот уж распространено, но тем, не менее. Я встречался с такими БД.
По-хорошему, сертифицированные СУБД должны ставиться на идентичные по уровню требований ОС, соответственно, в таком случае ничего на сырых носителях быть не должно.
Ключевое свойство запросов WITH состоит в том, что они обычно вычисляются один раз для всего основного запроса, даже если в основном запросе содержатся несколько ссылок на них. В частности, гарантируется, что операторы, изменяющие данные, будут выполняться ровно один раз, вне зависимости от того, будет ли их результат прочитан основным запросом и в каком объёме.
Однако от этой гарантии можно отказаться, добавив для запроса WITH пометку NOT MATERIALIZED. В этом случае запрос WITH может быть свёрнут в основной запрос, как если бы это был простой SELECT внутри предложения FROM основного запроса.
Это ни в коем случае не разработка. Это в чистом виде эксплуатация.
От дословного перевода на русский у меня кровь из глаз пошла. AD - служба каталогов от MS, предназначена для централизованного управления инфраструктурой.
ещё раз убедился в том, что реплики надо наливать из бекапов, а не с рабочих хостов (patroni в такое умеет);
ручное конфигурирование наличия синхронной реплики? Благородные доны не в курсе, что у patroni есть специальный параметр, отвечающий за наличие синхронной реплики? (извините, но почему-то на хабре не работает Ctrl+V/Shift+Ins, а набирать ручками - то ещё приключение)
Я прошу прощения, но хабр (именно хабр! на других ресурсах такого ограничения нет, увы мне) не позволяет Ctrl+V/Shift+Ins (ссылки были бы в предыдущем посте). Раздел "libpq - библиотека для языка C" в документации.
начиная с 10-й версии постгрес умеет в несколько хостов в строке подключения. И умеет в определение к мастеру подключение идёт, или как попало. А сейчас это определение умеет ещё больше всяких вкусностей. Соответственно, у меня тот же непраздный вопрос: а зачем общий IP и лишние сущности в виде haproxy&keepalived?
И второе у вас гвоздями etcd в качестве DCS прибит? зачем? Патроны не только в etcd умеют.
И да, у меня есть ролей для ансибла. Поэтому разворачивание кластера (причём не только патрони+етцд) - меньше 15 минут с учётом определения всех нужных данных.
Во! У меня одиссея нет, зато есть пгбаунсер. ВотЪ.
ЗЫ. Если есть патроны, то haproxy совсем не надо дёргать внешний скрипт, вполне себе достаточно http-check expect status 200 на нужный урл, который отдают патроны.
Потому что пользователю удобно - скачал и запустил, а не эти вот все apt get install
Справедливости ради, пользователю удобно в гуе найти программу по ОПИСАНИЮ! и поставить её из штатной репы дистра, щёлкнув мышкой (как оно в дебе называется, synaptic вроде? Не помню, я не пользователь, но у меня в консоли тоже есть поиск по описанию пакета: `eix -S`).
Безо всех вот этих вот: нашёл в интернете название, скачал непонятно откуда, поставил.
Слыхать, может и слыхал, но, оригинальная таблица называется "Популярные инструменты для бекапа PostgreSQL.". И в то время, когда я эту табличку делал, указанная вами утилита, да и многие другие, которые где-то как-то мимолётно упоминались, популярными не являлись. Так что, если у вас есть намного более объёмный список инструментов для создания резервных копий постгреса, то вы можете свой обзор оформить. Постгресовые админы БД вам спасибо скажут. А по одной утилите сюда вопросы кидать, я думаю, не стоит.
Прощу прощения за задержку с ответом. Но указанного инструмента нет в обзоре, потому что на момент формирования исходной таблицы этого инструмента ещё в природе не существовало. И я о нём узнал из вашего сообщения. Как-то вот прошёл он мимо меня, и в потоке новостей от https://planet.postgresql.org/ я упоминания о нём не помню, вполне возможно, что пропустил.
Т.к. реакции на Ctrl+Enter нет и неизвестно, то...
Откуда версия 16.18.1, если оригинальная - 16.8?
pgbackrest не умеет в S3?
Это очень дерзкое и весьма далёкое от реальности заявление: https://habr.com/ru/articles/820349/
А оригинал в коммуне ЖЖ я делал в 2019-м, и уже тогда pgbackrest умел в S3.
Как вы выглядите без тщательной проработки вопроса, публикуя столь недостоверную информацию, решайте сами.
Нет. Надо тестировать. Потому что, помимо хардлинков создаётся из старой версии и накатывается на новую полный дамп схемы. А тут возможны варианты, особенно при наличии large objects (https://postgrespro.ru/docs/postgresql/17/largeobjects), которые живут в системном каталоге, соответственно, попадают в упомянутый дамп схемы. Да, наличие подобных объектов не вот уж распространено, но тем, не менее. Я встречался с такими БД.
По-хорошему, сертифицированные СУБД должны ставиться на идентичные по уровню требований ОС, соответственно, в таком случае ничего на сырых носителях быть не должно.
Вот-вот. Удалили секретные данные из отовсюду, и при внезапном аудите поехала бухгалтерская отчётность. Умиляют меня вот эти вот требования.
Я привёл ссылку на перевод официальной документации. У каждого ПгПро (стандарт/энтерпрайз) своя документация.
Документация по ПГ: https://postgrespro.ru/docs/postgresql/12/sql-select#SQL-WITH
Это ни в коем случае не разработка. Это в чистом виде эксплуатация.
От дословного перевода на русский у меня кровь из глаз пошла. AD - служба каталогов от MS, предназначена для централизованного управления инфраструктурой.
Да и остальное не лучше.
разведка? Вариант спровоцировать "бытовую ссору" не рассматриваете?
ещё раз убедился в том, что реплики надо наливать из бекапов, а не с рабочих хостов (patroni в такое умеет);
ручное конфигурирование наличия синхронной реплики? Благородные доны не в курсе, что у patroni есть специальный параметр, отвечающий за наличие синхронной реплики? (извините, но почему-то на хабре не работает Ctrl+V/Shift+Ins, а набирать ручками - то ещё приключение)
Я прошу прощения, но хабр (именно хабр! на других ресурсах такого ограничения нет, увы мне) не позволяет Ctrl+V/Shift+Ins (ссылки были бы в предыдущем посте). Раздел "libpq - библиотека для языка C" в документации.
А ручками набирать - извините...
Любой клиент, использующий libpq + Java (у неё своя собственная библиотека, но данная возможность присутствует, проверено).
начиная с 10-й версии постгрес умеет в несколько хостов в строке подключения. И умеет в определение к мастеру подключение идёт, или как попало. А сейчас это определение умеет ещё больше всяких вкусностей. Соответственно, у меня тот же непраздный вопрос: а зачем общий IP и лишние сущности в виде haproxy&keepalived?
И второе у вас гвоздями etcd в качестве DCS прибит? зачем? Патроны не только в etcd умеют.
И да, у меня есть ролей для ансибла. Поэтому разворачивание кластера (причём не только патрони+етцд) - меньше 15 минут с учётом определения всех нужных данных.
Во! У меня одиссея нет, зато есть пгбаунсер. ВотЪ.
ЗЫ. Если есть патроны, то haproxy совсем не надо дёргать внешний скрипт, вполне себе достаточно http-check expect status 200 на нужный урл, который отдают патроны.
Админ шоколадки не пьёт!
Справедливости ради, пользователю удобно в гуе найти программу по ОПИСАНИЮ! и поставить её из штатной репы дистра, щёлкнув мышкой (как оно в дебе называется, synaptic вроде? Не помню, я не пользователь, но у меня в консоли тоже есть поиск по описанию пакета: `eix -S`).
Безо всех вот этих вот: нашёл в интернете название, скачал непонятно откуда, поставил.
Слыхать, может и слыхал, но, оригинальная таблица называется "Популярные инструменты для бекапа PostgreSQL.". И в то время, когда я эту табличку делал, указанная вами утилита, да и многие другие, которые где-то как-то мимолётно упоминались, популярными не являлись. Так что, если у вас есть намного более объёмный список инструментов для создания резервных копий постгреса, то вы можете свой обзор оформить. Постгресовые админы БД вам спасибо скажут. А по одной утилите сюда вопросы кидать, я думаю, не стоит.
Прощу прощения за задержку с ответом. Но указанного инструмента нет в обзоре, потому что на момент формирования исходной таблицы этого инструмента ещё в природе не существовало. И я о нём узнал из вашего сообщения. Как-то вот прошёл он мимо меня, и в потоке новостей от https://planet.postgresql.org/ я упоминания о нём не помню, вполне возможно, что пропустил.
Спасибо, поправил.
Егор, спасибо за очень важное уточнение! Исправил соответствующее описание.
Это не вот уж важный критерий, хотя бы потому, что ansible - ну совсем не единственный инструмент для централизованного конфигурирования.