Одного разу я зруйнував свій виробничий DB зі сплячим UPDATE і не мав нових резервних копій.Втратив ~30% доходу, кучу нервів і так занадто багато годин.Цей біль змусив мене побудувати і відкрити програмне забезпечення для резервного копіювання і моніторингу PostgreSQL, яке я тепер використовую повсюдно. Table of content Відкритий проект PostgreSQL Backup Історія про те, як я зламав DB і не зміг повністю відновитися Як я почав будувати проект Дорожня карта та майбутні плани Правила безпеки DB, які я тепер застосовую на кожному проекті Завантажити Про проект Open Source PostgreSQL Backup Я відкрив свій власний інструмент для моніторингу та резервного копіювання PostgreSQL. Я будую і використовую його трохи більше двох років. Спочатку я розробив його для моєї денної роботи та декількох проектів для домашніх тварин. Лише нещодавно мене вразило, що проект насправді виглядає досить добре, щоб показати публічно, він вже допомагає моїм друзям і може бути корисним для співтовариства. Go, gin, gorm, React, TypeScript, PostgreSQL — все вбудовано в Docker. Stack: По суті, це UI Wrapper навколо стандарту в налаштованому форматі, з великою кількістю додатків, які роблять UX менш болючим і додають інтеграції з зовнішніми службами зберігання та повідомлення. pg_dump What it can do: Заплануйте резервні копії (наприклад, щодня о 4 ранку або щонеділі опівночі) для PostgreSQL 13–17. Зберігайте стиснені резервні копії локально на сервері, в S3 або Google Drive (NS-сервери та FTP знаходяться на дорожній карті). Надіслати вам повідомлення після кожного резервного копіювання, що все гаразд ... або ні. Повідомлення є опціональними. Пінг вас в Discord, email, Telegram і Slack, якщо DB перестає відповідати. Він тільки попереджає після n невдалих перевірок (щоб уникнути фальшивих позитивних через збої мережі) і відображає графік доступності. Звичайно, проект є безкоштовним, відкритим кодом (MIT), самохостингом і поставляється з гуманним веб-інтерфейсом. Сайт проекту: https://postgresus.com/ https://postgresus.com/ На сайті GitHub: https://github.com/RostislavDugin/postgresus https://github.com/RostislavDugin/postgresus P.S. Якщо проект виглядає корисним і у вас є обліковий запис GitHub, ⭐️ Перші зірки насправді найважче отримати. I’d really appreciate a Історія про те, як я зламав DB і не зміг повністю відновитися У 2023 році у мене був проект з домашніми тваринами, який був обкладинкою ChatGPT (3.5). В основному, це був просто перепродаж доступу до API з гарним інтерфейсом інтерфейсу та скороченнями. Проект зростав, потім почав падати, і я нарешті продав його. до іншого сервера. PgBackRest У той момент, коли проект приносив близько 1500 доларів пасивно і досяг свого піку доходів, сталося щось погане: . I broke the data in the DB Це був п'ятничний вечір. я втомився, я відразу ж переходив від кодування до відповіді на повідомлення, повністю не орієнтований. За допомогою SSH та Я стрибнув у виробництво VPS і ввів щось на зразок: psql UPDATE users SET email = 'customer@email.com' WHERE email ILIKE '%%'; Потім я відволікався, щоб скопіювати правильну електронну пошту з чату і... натиснути Enter на «автопілот». . AFFECTED ROWS: 10 000 Це був єдиний раз за багато, багато років, коли я буквально відчув холодний піт на спині. Звичайно, я знав, що я повинен був зробити Спочатку, можливо, встановлюється а Але, як і в будь-якій історії жахів, основні правила безпеки були ігноровані, і все це переросло в катастрофу. Disclaimers SELECT SAVEPOINT Всі електронні листи користувачів були надписані.І ось ключова деталь: платіжні системи мають суворі правила - якщо користувач не може отримати доступ до платного сервісу, це величезне порушення. Я біг до резервних копій - і холодний піт став ще гіршим. Найновіший резервний копій був близько місяця 😐. Немає способу відновити з цього. З того часу нові платежі прийшли, передплати були скасовані (це означає, що я не міг просто відновити всіх - деякі люди вже пішли), і т.д. Як-то, протягом решти ночі і ранку, мені вдалося відновити близько 65% DB за допомогою скриптів за допомогою ідентифікаторів користувачів. Урок був вивчений. Як я почав будувати проект Час прийняття рішення: я буду будувати для себе інструмент резервного копіювання, який буде ping мене кожен день, що все гаразд! І відновити за пару кліків! І блекджек і мікросервіси! І я додаю кінцеву точку перевірки здоров'я API теж! Я зробив першу версію Postgresus приблизно за місяць на Java. Почав використовувати його. Нехай кілька друзів спробують його. Виявилося: це корисно. Декілька разів ці резервні копії врятували мене (і не тільки мене). Ім'я "Postgresus" з'явилося лише два місяці тому, перш ніж репо було просто названо . «Pg-Web Backup» На даний момент, Postgresus вирішує ці проблеми для мене: Це основний інструмент резервного копіювання, якщо проект невеликий або живе на VPS замість хмарної служби DB. Це інструмент резервного копіювання, якщо проект великий і живе в DBaaS зі своїми власними хмарними резервними копіями.Це резервне копіювання "тільки на випадок" (якщо хмара гине, блокується, DB випадково видаляється разом з хмарними резервними копіями через невиплату і т.д.). Дорожня карта та майбутні плани, які я планую підштовхнути проект у цих напрямках: Add more PostgreSQL-specific load monitoring (pg_stat_activity, pg_stat_system, pg_locks) with a friendly UI. Think of it as an alternative to postgres_exporter + Grafana, but bundled out of the box with backups. Observe and alert on slowdown of key queries. In my work project, there are tables and specific functions that are too early to optimize (if the hypothesis fails, we might drop them), but they could grow and slow down. For example, if INSERT INTO users (...) VALUES (...) starts taking more than 100 ms while the flow of new users is growing - we'll get a notification and go optimize. Collect query stats by CPU time and execution frequency to see where resources are actually going and what’s worth improving. Add more channels for notifications and more storage providers. Правила безпеки DB, які я тепер застосовую на кожному проекті Дозвольте мені нагадати вам про дві частини народної мудрості: Системні адміністратори поділяються на дві категорії: ті, хто ще не робить резервні копії, і ті, хто вже робить. Системні адміністратори поділяються на дві категорії: ті, хто ще не робить резервні копії, і ті, хто вже робить. Не просто створюйте резервні копії — регулярно перевіряйте, що ви можете відновити з них. Не просто створюйте резервні копії — регулярно перевіряйте, що ви можете відновити з них. З тих пір, як я розтратив DB мого проекту, я прийняв ці правила без винятку: Перед будь-яким оновленням завжди запускайте SELECT і переконайтеся, що ви торкаєтеся точно 1-2 рядків. Якщо зміни великі — встановити SAVEPOINT вручну. Проводьте «пожежну сигналізацію» з відновленням принаймні раз на 3 місяці: відновлюйте з хмарної копії та з локальної, так що коли це важливо, ви не знайдете, що немає даних, резервні копії не працюють, або відновлення тривають вічно. Протягом останніх двох років було кілька випадків, коли нам потрібно було відновлювати з резервних копій - кожен раз, коли це працювало, як в хмарі, так і через Postgresus. Завантажити Я сподіваюся, що цей проект буде корисним для широкого кола розробників, DBA і людей з DevOps. Я планую продовжувати розвивати його, щоб зробити його ще більш корисним у реальних сценаріях.
