Если у вас размер БД менее 100Гб, то достаточно простой конфигурации: MASTER => REPLICA => BACKUP. Если размер БД более 100Гб, то стоит знать про разные подходы к резервному копированию.
pg_basebackup работает по принципу копирования файлов: коприуется весь кластер целиком.
На момент завершения копирования, файлы могут быть изменены.
Для того чтобы вернуться к консистентному состоянию, необходимо "проиграть" WAL-файлы.
pg_probackup инкрементальное копирование, т.к. копируются только измененные данные.
Для максимально эффективного инкрементального бекапа, можно собрать PostgreSQL со специальным трекером
изменений страничек (page tracking). При этом, во время бекапа, pg_probackup будет использовать данные
этого трекера, чтобы понимать, какие страницы были изменены. Благодаря этому отдельному трекеру,
для PostgreSQL бекап - не транзакция, как в случае с pg_dump и резервное копирование выполняется через
копирование файлов.
Напомню, что pg_dump (pg_dumpall) выполняет выборку данные в рамках одной большой
транзакции с уровнем изоляции REPEATABLE READ.
Бэкапы хорошо проверять. Иногда это можно сделать с пользой для вашего клиента: например, ежедневно восстанавливать дневной бэкап на выделенный сервер для аналитиков. Как правило у аналитиков тяжелые запросы и они могут негативно сказаться на производительности основного сервера. Т.е. мы и бэкап проверили (как правило атоматический цикл) и снизили нагрузку. Подобные дневные бэкапы также могут использовать тестировщики для проверки новых фич на объеме данных.
С момента создания UUID стали активно использовать в качестве первичного ключа во многих БД, особенно в распределенных системах. Но UUID v4 (random) не всегда удобен, т.к. не удобно сортировать и партиционировать. Выделяют еще такие сомнительные недостатки, что в UUIDv1 хранится MAC-адрес и временная метка, что может нести риски безопасности. Медленные UUIDv3 и UUIDv5, т.к. используют хэширование.
Преимущества UUID v7: уникальные, монотонные (первые 48 бит - это Unix timestamp), т.е. удобные для сортировки и партиционирования.
Важные обновления:
Команда GoLand адаптировала DFA (data flow analysis), используемый в CLion, для поиска ошибок в коде. DFA покажет ошибки, связанные с неверными условиями (condition is always false) даже для случаев когда все сильно запутано и перед условием есть еще куча условий и циклов. Также теперь можно увидеть потенциальные nil pointer dereference.
JetBrains активно продвигает свой AI Assistant и я планирую его использовать и сравнить с Github Copilot, который использую сейчас. О своем опыте расскажу об этом в следующих выпусках подкаста.