Комментарии 45
Я скоро буду заниматься Постгре после MSSQL, и, соответственно, буду проходить все стадии. Отрицание уже прошел, теперь гнев. А вы добрались до принятия?
Для 1с postgres достаточно хорош. Даже обгоняет ms sql ценой повышенного расхода ЦПУ. https://habr.com/ru/articles/723642/
Для тяжёлых задач больше 5 терабайт есть платные enterprise варианты где недостатки пытаются компенсировать https://dzen.ru/a/ZEaO0d7tql_rI52a
Для ипортозамещения вполне рабочий вариант учитывая ситуацию
Чем больше читаю про postgress, тем меньше хочется это использовать. MS SQL для меня очень удобный и быстрый сервер. Настроенные автоматические бэкапы всех баз вместе с Master позволяют жить спокойно. Очень удобно использовать синонимы, в postgress такого нет. Ну и много других возможностей, с которыми уже сроднился.
К сожалению с MS SQL рано или поздно придется соскакивать . И не только из за политики Microsoft в РФ.
Во первых они в последних версиях сильно повысили приоритет оптимизатора запросов в принятии решений - какой план более хорош. Даже правильные индексы не указ. 1С например хинты не поддерживает. Я за ИИ в СУБД главное чтобы он со здравым смыслом был и давал план быстрее, а не бесконечный. Поэтому мне пришлось откатить режим совместимости назад на 2008R2
Во вторых они Windows, где все это крутится уже с декстопов позиционируют на WaaS (Windows as service) Overview of Windows as a service - Windows Deployment | Microsoft Learn . Что по факту превращается в цифровую тюрьму с принудительными обновлениями. Пока это для Home edition. Но их стратегия понятна - всех загнать в облако, или прибить гвоздями к серверу обновлений все ради блага пользователей.
Я удивляюсь почему не смотрят в сторону Oracle. Там даже коды регистраций не нужно при инсталляции вводить лицензировании практически на доверии. А архитектурное качество выше чем MS SQL
Ну так надо не про бред ChatGPT читать, а официальную документацию. У PostgreSQL безусловно есть проблемы, но зачем искать их на пустом месте, а затем мужественно преодолевать?
А что ChatGPT неправильно определение привел? Из официальной документации. Его кстати хорошо использовать чтобы увидеть "общее мнение"
А pg_basebackup да бэкапит. А восстанавливать пробовали? Там официальная инструкция не для слабонервных , поскольку по сути предлагают реплику развернуть
Не только пробовал, но и проходил соответствующие учебные курсы, с обязательным выполнением лабораторных практикумов. А уметь разворачивать реплики полезно (как и знать возможности инструмента, с которым работаешь).
Что касается ChatGPT, то по отношению к официальной документации (прекрасной кстати) - это из разряда "Мойша напел". Нейросетки любят галлюцинировать, именно это и называется бредом.
В бесплатном Postrgres нет (если конечно Вы не считаете pg_dump\pg_restore которые по сути аналоги BCP бэкапом)
В платных например от Postgres pro https://www.postgrespro.ru/ или другие варианты которые порекомендовали в комментах тут
https://habr.com/ru/articles/791726/ есть усовершенствованные инструменты
возможно будет близко к удобству MS SQL , надо просто попробовать и составить мнение.
Enterprise версию на пробный период (несколько месяцев ) дают бесплатно под гарантийное письмо о последующем удалении и NDA
Просто кроме бэкапа\рестора есть еще вопросы верификации бэкапа. А в Postgres с этим непросто.
А почему вдруг бесплатные pg_basebackup, pg_probackup, pg_backrest, barman перестали делать полный бэкап? Или они платными стали все вместе одновременно?
GitHub - postgrespro/pg_probackup: Backup and recovery manager for PostgreSQL ну Вы наверное это все читали?
Из разряда собери\скомпили сам. PostgresPro почемуто включает эту утилиту в верию не ниже PostgresPro standard , которая уже платная
А pg_basebackup это да в базовой версии есть, вот только restore там нет, а вместо нее инструкция как по результам pb_basebakup поднять реплику.
В этом и проблема Postgres что простых средств сделать полный бэкап в базовой бесплатной версии нет. А гонять по клиентам 1С франчайзи подготовленного Postgres админа это лишние косты (когда раньше на MS SQL все можно было в Gui сделать человеком уровня database operator)
Поэтому для комфорта нужно покупать что то платное типа PostgresPro стандарт, но тогда мы вправе ожидать что там будет не хуже по комфорту чем в MS SQL хотябы. А это так?
Вы как будто вчера postgres увидели, а сегодня статью решили написать. https://postgrespro.github.io/pg_probackup/#pbk-install - совершенно обычная установка пакетов в linux, никакой сборки.
Если вы не понимаете как работает postgres, то зачем пишете статьи? Ознакомьтесь что такое кластер в их понимании, и поймете что пока работает только бэкап всего инстанса. При подходе 1 база - 1 кластер все становится совершенно просто и понятно. Вся эта ситуация давным давно разжевана в миллионе телеграмм каналов, да и на хабре встречалась.
pg_backrest, barman - про это вы даже не упомянули, хотя они куда проще чем предлагаемый вами кадавр.
В общем, простите за грубость, детский сад какой-то. Человек, который ничего толком не знает и не понимает даже базовых вещей в обсуждаемом предмете, пытается этому предмету учить других.
Может стоит снести статью в черновики как глупость?
Если вы не понимаете как работает postgres, то зачем пишете статьи? Ознакомьтесь что такое кластер в их понимании, и поймете что пока работает только бэкап всего инстанса.
А за чем Вы комментируете то что не читаете?
Я в начале четко написал
"предыдущей серии Инструкция по бэкапу одной базы в Postgres - миф или реальность? мы выяснили, что база данных в Postgres это лукавый термин, и база в Postgres не имеет полноценных средств резервного копирования, в отличии от Instance Postgres. "
pg_backrest, barman - про это вы даже не упомянули, хотя они куда проще чем предлагаемый вами кадавр.
Вообщето статья про File level backup, но вы комментируете . я понимаю что Вас бесит.
Кто то привыкший к комфорту Oracle или MS SQL где все нужное из коробки, ленится пробежатся по всем git где все "нужное есть" надо просто потратить время все перепробовать.
Я в начале четко написал
"предыдущей серии Инструкция по бэкапу одной базы в Postgres - миф или реальность? мы выяснили, что база данных в Postgres это лукавый термин, и база в Postgres не имеет полноценных средств резервного копирования, в отличии от Instance Postgres. "
Речь про статью, где вы утверждаете, что pg_dump блокирует запись в таблицы во время своей работы?
Речь про статью, где вы утверждаете, что pg_dump блокирует запись в таблицы во время своей работы?
А где там это писал? Я только два раза употребил слово блокировка.
Я привел данные из трассировки где есть Lock table
LOCK TABLE public._document21655_vt21690 IN ACCESS SHARE MODE NOWAIT
но там режим указан.
Вы сознательно манипулируете фактами - выдаете свои представления за авторские или это другое?
А где там это писал?
Не помните, что писали в собственной статье? Пожалуйста: "С точки зрения целостности все хорошо – используется уровень изоляции SET TRANSACTION ISOLATION LEVEL REPEATABLE READ. Он достаточно жесткий, т.е. работа параллельных процессов на запись во время длительного бэкапа будет парализована. Каждая таблица блокируется полностью до окончания команд COPY. "
Использую wal-g и mini-io. Целостность бекапов можно проверить разворачивая бекапы в копию базы в докере и sql запросом на какие то данные. Если true все ок( либо на тестовый стенд.)
Насколько это проще для программиста (не админа) чем холодный бэкап? с виду он похож на pg_basebackup только с возможностью делать инкрементальные и разностные. Но в Postgres сложно не сделать бэкап а восстановить корректно как правило
А поделитесь пожалуйста опытом, а то у меня эта связка не завелась.
Видел в каком то мастер-классе по pg опцию, которая заставляет pg использовать контрольные суммы при записи строк для валидации целостности
Таким образом при восстановлении чего либо в Postgres Вы можете быть уверены в качестве восстановления, только «потрогав» все таблицы и индексы. А когда их тысячи (как в любой типовой базе 1С ) это занимает значительное время.
Это верно для абсолютно любой базы и вообще любого бэкапа, в том числе файлового.
Не "потрогав" данные в бэкапе и не сравнив это с оригиналом, бит в бит, вы никогда не можете быть уверены в качестве восстановления на 100%.
В самом лучшем случае можно сравнивать хеши которые строятся в процессе создания бэкапа, но даже в этом случае чтобы убедиться что всё в порядке, придётся прочитать все данные в бэкапе.
Можно проверить наличие файлов при старте - да, но это не даёт никакой уверенности, потому что данные внутри этих файлов, где-то глубоко внутри, могут быть повреждены и выяснится это только когда к ним кто-то полезет.
Но если очень хочется сделать quick check - то в Postgres это делается парой простых запросов при старте, перед тем как решить отпускать ли это для всех, и разумеется это займёт некоторое время при очень большой базе.
На самом деле, даже если вы сделали бэкап и сравнили его с оригиналом трижды, у вас всё равно не может быть 100% уверенности что всё в порядке - мало ли что с данным в бэкапе случится когда он понадобится через пару недель или месяцев, bit rot никто не отменял, и поможет тут только хороший хэш и чтение всех данных (я именно так и проверяю бэкапы периодически).
По поводу контрольных сумм - на современных процессорах они вообще не влияют на производительность, там в худшем случае менее 1%, и они включены по умолчанию в последних версиях (но может зависеть от дистрибутива и мейнтейнера). Впрочем, они проверяются только при обращении к данным - т.е. опять таки, не прочитав всё, не узнаете есть ли проблемы - и это верно не только для Postgres.
Postgres отлично бэкапится и в процессе работы, без остановки - простым File Level Backup, с индексами и всеми потрохами, даже простым rsync/restic/rustic/borg/etc, нужно только обернуть его в pg_start_backup()/pg_stop_backup() - на выполнение запросов это не повлияет, разве что их замедлит.
Да, если у вас всё не в одном месте, вам придётся позаботится о симлинках и прочих странных местах где вы храните таблицы, но есть куча инструментов которые это автоматизируют (бесплатных, да).
И наконец, есть Continuous Archiving, который настолько надёжен насколько надёжны ваша сеть и диски - то есть если исключить потенциальную порчу данных в процессе передачи по сети, записи на диск, а также повреждение оных в памяти или на диске, у вас будет всегда готовая к использованию копия базы, не говоря уже про бонусы вроде PITR и даже delayed replication (когда secondary отстаёт от primary на заданное время, но без потери актуальных данных).
Всё это хорошо описано в документации, даже с примерами, не говоря уже о бесчисленных ресурсах посвященных этой теме.
PS: У меня за более чем 15 лет работы с Postgres (начиная с версии 8.0), никогда не было проблем ни с бэкапами, ни с их восстановлением, которое периодически производится как в случае жёстких падений железа так и для "взгляда в прошлое".
Впрочем, они проверяются только при обращении к данным - т.е. опять таки, не прочитав всё, не узнаете есть ли проблемы - и это верно не только для Postgres.
Прямой вопрос - есть ли всетаки в Постргесе аналог верификации бэкапа? Например в MS SQL online бэкап идет на уровне страниц, и Verify backup соответственно по ним контрольные суммы проверяет.
Но если очень хочется сделать quick check - то в Postgres это делается парой простых запросов при старте, перед тем как решить отпускать ли это для всех, и разумеется это займёт некоторое время при очень большой базе.
Все Индексы очевидно не потрогает очевидно поэтому я так пониманию нужно не ниже vacuum запускать.
Postgres отлично бэкапится и в процессе работы, без остановки - простым File Level Backup, с индексами и всеми потрохами, даже простым rsync/restic/rustic/borg/etc, нужно только обернуть его в
pg_start_backup()/pg_stop_backup()- на выполнение запросов это не повлияет, разве что их замедлит.Да, если у вас всё не в одном месте, вам придётся позаботится о симлинках и прочих странных местах где вы храните таблицы, но есть куча инструментов которые это автоматизируют (бесплатных, да).
Вы каким бесплатным и удобным инструментом пользуетесь?
Прямой вопрос - есть ли всетаки в Постргесе аналог верификации бэкапа?
Уже несколько версий как есть, прям так и называется - pg_verifybackup.
Вы каким бесплатным и удобным инструментом пользуетесь?
В основном это barman, но кое-где и pgbackrest. Но они, насколько я помню, не для Windows. Под Windows вообще мало чего для Postgres, по вполне объяснимым причинам.
Если для вас удобство это "один клик" и GUI - тогда увы, это не тот случай. Для меня удобство - один раз настроил и забыл, оно просто работает.
Уже несколько версий как есть, прям так и называется - pg_verifybackup.
Я кажется про него читал, прочитал еще раз и как понимаю этот pg_verifybackup не дотягивает до опции checksum при бэкапе MS SQL
В pg_verifybackup проверяются контрольные суммы файлов и их соответствие https://www.postgrespro.ru/docs/postgrespro/16/app-pgverifybackup
А в MS SQL проверяются контрольные суммы страниц
https://learn.microsoft.com/ru-ru/sql/t-sql/statements/backup-transact-sql?view=sql-server-2016
CHECKSUM
Указывает, что при операции резервного копирования выполняется проверка контрольной суммы и наличия разрывов на каждой странице (если эти проверки включены и доступны), а также будет создаваться контрольная сумма для всей резервной копии.
Использование резервных копий проверка sumsums может повлиять на пропускную способность рабочей нагрузки и резервного копирования.
В основном это barman, но кое-где и pgbackrest. Но они, насколько я помню, не для Windows
Попробую , Linux это неизбежно
Прямой вопрос - есть ли всетаки в Постргесе аналог верификации бэкапа? Например в MS SQL online бэкап идет на уровне страниц, и Verify backup соответственно по ним контрольные суммы проверяет.
Емнип, pg_basebackup по умолчанию проверяет контрольные суммы (разумеется, если они были предварительно включены)
Откройте для себя pg_probackup
Просто, надёжно, удобно.
И перестаньте использовать Windows для PG, пожалуйста.
для 1С мне доступны только два бесплатных варианта Postgres это сборка от 1С и PostgresPro (базовая) но ни в той ни другой там pg_prodbackup нет. Есть только в платных PostgresPro
Если вытянуть его бесплатно с git то нужно собрать скомпилить встроить. Будет время доберусь.
И перестаньте использовать Windows для PG, пожалуйста.
А что в linux Postgres в Oracle превращается что ли? Сколько слышу это утверждение никто не может объяснить разницу
По своим объективным тестам Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С / Хабр (habr.com)
Я существенную разницу не увидел когда погонял на Linux , структура процессов и хранения одинакова, разницы в производительности не заментно. Понятно что Microsoft своей политикой уже делает работу в Win некомфортной, но инерцию никто не отменял
для 1С мне доступны только два бесплатных варианта Postgres это сборка от 1С и PostgresPro (базовая) но ни в той ни другой там pg_prodbackup нет. Есть только в платных PostgresPro
pg_probackup бесплатен, и устанавливается из обычного репозитория. Ничего не надо собирать для популярных, в том числе и импортозамещённых. дистрибутивов.
Я существенную разницу не увидел когда погонял на Linux , структура процессов и хранения одинакова, разницы в производительности не заментно.
Мой опыт говорит об обратном: разница при работе 1с с PG на Windows и Linux существенна. Жалобы на медленную работу 1с при переносе сервера БД на линукс пропадают. Возможно, это всё зависит от других вещей, например - расположения на одном сервере сервисов приложения и БД. Но при этом исчерпания ресурсов не было замечено.
Тот же Дорошкевич Антон говорил на пгконфе, что использование ПГ на виндовс в составе 1с возможно для небольшого количества клиентов, по-моему, до 15.
По факту, PG для работы использует вызов fork, который в Windows приходится эмулировать.
Также, при работе в Windows вы теряете возможности: например JIT компиляцию, использование расширений. Тот же pbk больше не поддерживается в Windows.
Вот вы скажите
Зачем чтобы иметь возможность восстановления на произвольный момент времени нужно делать бекап всего кластера? А может у меня там сотни БД?
Такого бреда нет ни в MySQL ни Oracle. Да и в MS SQL вероятно тоже.
Это потому что в PostgreSQL кластером называют то, что в Oracle называют инстансом. И да, чтобы иметь возможность восстановиться на произвольный момент времени, надо иметь полный физический бакап инстанса (а как иначе?). Ну а то что там сотни БД (то что в Oracle называется схемами), то это же вы сами так решили сделать? Физика бакапится вся целиком, со всеми базами которые там у вас есть и никак иначе.
Тут детально изложено Инструкция по бэкапу одной базы в Postgres – миф или реальность / Хабр (habr.com) что база в Postgres это лукавый термин , поэтому все бэкапы с учетом WAL только на уровне кластера.
И в чём же состоит "лукавость"?
Когда нельзя сделать Online бэкап одной базы (а не выгрузку в стиле BCP \ EXP ака pg_dump) недостаточно?
А с кросс запросами в одном кластере как? Akinjide Bankole - Cross Database Querying in PostgreSQL
Чем глубже копаешь , тем больше понимания что по сравнению с понятием база данных в MS SQL в Postgres это просто набор метаданных и не более
Вы путаете тёплое с мягким. Online бакап одной базы в PostgreSQL выполнить можно, но только логический. Физический горячий бакап подразумевает, что вы работаете со всем инстансом целиком (который в PostgreSQL называется кластером), просто исходя из своей природы и ровно также как и в других РСУБД.
Что касается запросов между базами данных, то для этого есть dblink-и, ровно также как в Oracle, например. И всем этим надо уметь пользоваться иначе что-то обязательно поломается. Вы же, публикуя свои не очень грамотные в техническом отношении статьи, оказываете аудитории медвежью услугу. Не будь таких статей на Хабре (и в области видимости ChatGPT), возможно большее количество людей читало бы общедоступную и очень грамотно написанную документацию.
просто исходя из своей природы и ровно также как и в других РСУБД.
Вы за другие РСУБД решили ответить . По Вашему ms sql тоже делает "логический бэкап " одной базы. Вот вам термин уже в мозг внедрили и все тупик.
Чем pg_dump отличается от bcp? Подумайте
А про dblink в рамках инстанс - какой там join пойдет - nested loop или получше?
Ещё раз убеждаюсь что лучше начинать с СУБД где архитектура продумана
Надо понять работу РСУБД, начиная с ACI(D), и многие вещи перестанут быть бредом.
в Oracle автономные БД появились недавно. И среди моих знакомых никто не пользуется контейнерными БД, слишком муторно.
Как неПросто сделать холодный бэкап Postgres