Будет рассмотрен вклад Яндекса в следующие базы данных.
В этой статье я расскажу, как мы выбирали и внедряли средства резервного копирования и восстановления пользовательских данных для закрытого контура заказчика в условиях ограниченности ресурсов, а также познакомлю с частью системного архитектурного стека нашего продукта.
Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret "Инструменты создания бэкапов PostgreSQL" . В конце обновленная сводная таблица по инструментам
Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.
WAL-G — простой и эффективный инструмент для резервного копирования PostgreSQL в облака. По своей основной функциональности он является наследником популярного инструмента WAL-E, но переписанным на Go. Но в WAL-G есть одна важная новая особенность — дельта-копии. Дельта-копии WAL-G хранят страницы файлов, изменившиеся с предыдущей версии резервной копии. В WAL-G реализовано довольно много технологий по распараллеливанию бэкапов. WAL-G работает гораздо быстрее чем, WAL-E.
Предлагаю ознакомиться с расшифровкой доклада начала 2019 года Андрея Бородина "Резервные копии с WAL-G. Что там в 2019?"
Предлагаю ознакомиться с расшифровкой доклада начала 2020 года Георгия Рылова "WAL-G: новые возможности и расширение сообщества"
У меинтейнеров open-source возникает множество проблем по мере их роста. Как писать все больше требуемых фич, чинить все больше issues'ов и успевать смотреть все больше pull request'ов? На примере WAL-G(backup-tool for PostgreSQL) расскажу про то, как мы решали эти проблемы, запустив курс по Open-source разработке в университете, чего мы добились и куда будем двигаться дальше.
Point in Time Recovery (PiTR) — это восстановление базы данных на какой‑то конкретный момент времени (с точностью до секунд или до конкретной транзакции).
PiTR невероятно полезен для восстановления базы данных после того, как «случилось непоправимое». Если достаточно точно выбрать точку на которую восстанавливать базу, то можно восстановить базу данных практически без потери данных.
В этой статье мы рассмотрим классический PiTR и еще два способа путешествовать во времени быстрее, и уменьшить количество операций, которые надо выполнять руками.
Возможно ли не замечать «лишних» 30 Tb данных на SSD при живом настроенном мониторинге и героически их обслуживать? Запросто, а ответы на вопросы кто же эти наблюдательные люди, как им это удалось и причем здесь PostgreSQL — ниже.