複雑なDB設定のためのDev環境？

Question

私は複雑なアプリケーションの唯一の開発者であり、開発チームを構築するために必要なところまで成長しました。私たちのシステムはバックエンドDBとしてMySQLを搭載した〜250,000 LOCのPHPアプリケーションです。

プロダクションWebサーバーと計算ノードを完全に複製するステージングサーバーがあります。過去には、私はステージングにコミット/プッシュしてテストを実行し、すべてをデバッグした時点でプロダクションに移行しました。ステージングサーバーが本番DBサーバーにヒットすると、MySQLの変更、挿入、削除などのテストに非常に注意を払っているため、これは非常に便利で問題はありませんでした。

私は唯一の開発者であるため、MySQLサーバをステージングまたはデベロッパークローンに複製する道を進んでいません。これは、テーブルルックアップのための一貫したハッシングアルゴリズムを使用して、4つの本番DBサーバーにわたって分割された数千のテーブルを扱うためです。私はどのようにクローンを作成し、これらのDBサーバーを同期させることができるのか分かりませんでした（それぞれが64コアの8コアです）。総DBサイズは〜300GBです。このように多くのデータを同期させることは、小さなdev環境ではほとんど不可能に近いようです。言うまでもなく、私がそれらを同期させておけば、dev/staging環境は非常に遅くなり、使用できなくなる可能性があります。

私はテストデータを構築することを考えていましたが、スキーマを同期させておくだけでしたが、devsがコード化してデバッグするための実動データを見たいと思います。アプリケーションの性質上、開発者は本番用のDBサーバーに移入するのと同じデータを参照することが重要です。

私の質問は、このシナリオでは、開発環境のために何をすべきですか？私はdevsにシステムの複雑な部分をコード化するスキーマを自由に使いたいと思っていますが、実際のスキーマ/データでそれらを演奏したくはありません。また、すべてのDBサーバーのオンサイトとオフサイトの両方の毎時バックアップを毎日行うことに注意してください。私はMySQLのテーブルをロールバックすることはできますが、それは苦労し、何らかのダウンタイムを必要とするかもしれません。私は、最善の選択肢は、この必要性を最初に避けることだと考えています。

他には何ができましたか？私は、FacebookやGoogleのような場所では、開発者のマシンにDB設定全体を複製するので、私が気づいていないセットアップ/プロセスがなければならないとは思っていません。

この長い記事を読む時間をとってくれてありがとうと私はあなたが持つ可能性のあるアドバイスを楽しみにしています。

Answer 1

シンプルで効果的ですが強制できない戦術は、MySQLトランザクションを使用することです。私たちは小規模なチームと小さな開発サーバーを持っており、これは私たちのためにうまくいきました。データベースラッパークラス（またはそれに類するもの）をお持ちの場合は、トランザクションの作成時にトランザクションを開始し、トランザクションが破棄されるとロールバックさせることができます。明らかに、誰かがそこでコミットを呼び出すことも、手動で接続を開くこともできますが、それは役に立ちます。小規模な開発チームは、おそらくこの戦略を使用することができます。新しいチームメンバーにパターンを伝えるのは簡単なので、これ以上のことはありません。