一度、私は眠気のあるアップデートで私の生産DBを破壊し、新鮮なバックアップがありませんでした. 収入の30%を失い、神経のバックアップと時間のバックアップが多すぎました. その痛みは、私は今、あらゆる場所で使用しているPostgreSQLのバックアップとモニタリングツールを構築し、オープンソースにしました。 Table of content オープンソースのPostgreSQL Backup Projectについて 私がDBを破って完全に回復できなかったことの物語 How I started building the project プロジェクトを始めた方法 ロードマップ & Future Plans DBのセキュリティルールは、すべてのプロジェクトに適用されます。 Wrapアップ オープンソースのPostgreSQL Backup Projectについて PostgreSQL をモニタリングしバックアップするための独自のツールを開設しました. I have been building and using it for a little more than two years. Initially, I have developed it for my day job and a couple of pet projects. 最近、このプロジェクトは実際に公表するのに十分に良いように見え、すでに友人たちを助けており、コミュニティに役立つ可能性があります。 Go、Gin、Gorm、React、TypeScript、PostgreSQL — すべてはDockerに包装されていた。 Stack: 基本的に、それは標準の周りのUIの包装です。 カスタマイズされた形式で、UXをより痛みやすくし、外部のストレージおよび通知サービスとの統合を追加するいくつかのエキストラを提供します。 pg_dump What it can do: PostgreSQL 13-17 用のスケジュールバックアップ(例えば、毎日午前 4 時または毎週日曜日の深夜) 圧縮されたバックアップをサーバー上、S3 または Google Drive (NS サーバーと FTP はロードマップにあります) にローカルに保存します。 バックアップごとに、すべてがうまくいっているか否かというメッセージを送信します。 Discord、Email、Telegram、Slack であなたをペンギンすると、DB が応答を停止します. It only alerts after n failed checks (to avoid false positives due to network glitches) and displays a availability graph. ネットワークのトラブルによる偽ポジティブを避けるために、N 失敗したチェックの後にのみ警告します。 もちろん、プロジェクトは無料で、オープンソース(MIT)、自己ホストであり、ヒューマンウェブUIを搭載しています。 プロジェクトサイト: 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)の包装物だったペットプロジェクトがありました。基本的に、それはすてきなUIとショートカットでAPIアクセスをリセールしただけでした。プロジェクトは成長し、その後低下し始め、私はようやくそれを販売しました。 別のサーバーへ PgBackRest プロジェクトが受動的に約1500ドルを調達し、収益ピークに達した瞬間、悪いことが起こった。 . I broke the data in the DB それは金曜日の夜でした。私は疲れました、私はすぐにコードからメッセージに返信するように切り替え、完全に焦点を当てませんでした。 SSHと、 私は生産VPSに飛び込み、以下のようなものを入力しました。 psql UPDATE users SET email = 'customer@email.com' WHERE email ILIKE '%%'; その後、私はチャットから正しい電子メールをコピーするために分散し、...「Autopilot」にEnterをタップしました。 . AFFECTED ROWS: 10 000 それは、何年もの間、私が文字通り背中に冷たい汗を感じた唯一のときでした。 : of course, I knew I should have done a まず、もしかしたらA しかし、あらゆるホラーストーリーと同様に、基本的な安全規則は無視され、すべてが災害に転じた。 Disclaimers SELECT SAVEPOINT すべてのユーザーの電子メールが書かれた。そして、ここに重要な詳細があります:支払いシステムには厳格なルールがあります - ユーザーが有料サービスにアクセスできない場合、それは大きな違反です。 私はバックアップに駆けつけました - 冷たい汗がさらに悪くなりました. 最新のバックアップは約1ヶ月前のものです. それから復旧する方法はありません. その時から新しい支払いが来て、サブスクリプションがキャンセルされました (つまり、すべての人を復元することはできませんでした - いくつかの人がすでに去りました) など。 どうにかして、残りの夜と朝、私はユーザIDを使用してスクリプトを通じてDBの約65%を再構築することができました。 レッスンは学んだ。 How I started building the project プロジェクトを始めた方法 決断の時間:私は毎日、すべてがうまくいっていることを私にペンギンするバックアップツールを自分自身に構築するつもりです! そして数クリックで復元します! そしてブラックジャックとマイクロサービス! そして私はAPIの健康チェックエンドポイントも追加します! Postgresus の最初のバージョンを Java で約 1 か月で作成しました. 使用を開始しました. いくつかの友達に試してみてください. 私のニーズと彼らのフィードバックに基づいてそれを磨き続けてください. 何回かそのバックアップが私を救ってくれました(私だけではありません) 「Postgresus」という名前は、リポが単に呼ばれる前、わずか2ヶ月前に現れました。 . 「pg-web-backup」 現時点で、Postgresusは私にとってこれらの問題を解決しています: これは、プロジェクトが小さい場合、またはクラウドDBサービスではなくVPSで生活している場合の主なバックアップツールです。 それはバックアップツールです プロジェクトが大きなもので、独自のクラウドバックアップを持つDBaaSに生きている場合 (クラウドが死ぬ場合、ブロックされる場合、DBが支払いがないためにクラウドバックアップと共に偶然削除されるなど) それは、クラウドが消えてもプランBがないときに、不幸な0.01パーセントに終わるよりも、常にダブルバックアップを持っている方が良いです。 Roadmap & future plans I am planning to push the project in these directions: プロジェクトをこれらの方向に推し進める予定です。 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のセキュリティルールは、すべてのプロジェクトに適用されます。 民衆の知恵の二つの部分を思い出させてください。 システム管理者は2つのカテゴリーに分けられます:まだバックアップしていない人と、すでにやっている人。 システム管理者は2つのカテゴリーに分けられます:まだバックアップしていない人と、すでにやっている人。 バックアップをするだけではなく、実際にそれらから復元できるかを定期的にテストしてください。 バックアップをするだけではなく、実際にそれらから復元できるかを定期的にテストしてください。 私のプロジェクトのDBを廃棄して以来、私は例外なくこれらのルールを採用しました。 任意のアップデートの前に、常に SELECT を実行し、正確に 1-2 行をタップしていることを確認してください。 変更が大きい場合は、手動で SAVEPOINT を設定します。 少なくとも3ヶ月に1回は「火災アラーム」を実行し、復元:クラウドコピーから復元し、ローカルコピーから復元するので、重要なのは、データがないこと、バックアップが機能しないこと、または復元が永久にかかることを発見しないことです。 過去2年間で、バックアップから復元する必要があるケースがいくつかありました - クラウドやPostgresus経由の両方で動作するたびに。 Wrapアップ このプロジェクトは、幅広い開発者、DBA、DevOpsの人々に役に立つことを願っています。現実世界のシナリオでさらに役に立つように進化し続ける予定です。
