最新のWebアプリケーションを開発する場合、バージョン管理システムを使用する利点を過小評価することは困難です。 開発した製品のファイルに関しては、最初のリビジョンからいつでも生産のあらゆる段階を追跡できます。 これを支援するツールは今日普及しており、開発中の良い形と見なされており、多くの場合、アプリケーションなしでの生産の成功は原則として不可能です。 また、ファイルではなくプロジェクトデータベースの変更を追跡する必要が生じた場合、どのような機会がありますか？ カットの下で、私が慣れ親しんでいなければならなかった既存のツールに関する情報を共有します。
1. PHP SQLDIFF、別名SQLDiff
（ http://phpsqldiff.sourceforge.net/ ）2つのデータベースのテーブル間の完全な違い（構造とデータの両方）を確認できるPHPスクリプト。 このツールには、構造またはデータを自動的に同期する手段はありません-視覚情報のみが提供されます。 もう1つの重大な欠点は、データベースにのみ接続できることです。データベースには直接アクセスできます（sshトンネル経由ではなく）。 大量のデータの処理速度が遅い（pear-moduleを介して処理します。これは、目新しさや速度のいずれでも輝きません）。 このスクリプトは、異なるテーブル間の違いを理解して視覚的に表示する必要がある場合に、開発者にとって非常に役立つと思います-便利なインターフェイス、迅速なセットアップがあります。 私は、同期プロセスを自動化するために使用できる深刻なツールとしてではなく、理論的には同一であるはずのテーブルの非同期化をすばやく理解するための便利なポケットユーティリティとしてより特徴づけています。
2. LIQUIBASE
（ http://www.liquibase.org/ ）Javaの便利で多機能で使いやすいデータベース構造移行ツール。 ジェンキンスと組み合わせて使用する場合、私はこのプラスを見ます。
例（host1はデータベース構造のコピー元のサーバー、host2はhost1から構造の転送先のサーバーです）：
java -jar liquibase.jar --driver=com.mysql.jdbc.Driver \ --classpath=mysql-connector-java-5.1.xx-bin.jar \ --logFile=db.ExampleChangelog.xml \ --url="jdbc:mysql://host2" \ --defaultSchemaName=db_name \ --username=username \ --password="password" \ --referenceUrl=jdbc:mysql://host1 \ --referenceUsername=username \ --referencePassword="password" \ diffChangeLog > ChangeSet.xml
変更セットをxml形式で生成し、さらに移行すると、host2のデータベース構造がhost1と同じ状態になります。
移行を開始します。
java -jar liquibase.jar --driver=com.mysql.jdbc.Driver \ --classpath=/path/to/classes \ --changeLogFile=ChangeSet.xml \ --url="jdbc:mysql://host2" \ --username=user \ --password="password" \ migrate
移行後、変更セットが空であることを再度確認することは理にかなっています。
テーブルとフィールドの同期だけでなく、インデックス、キーもあります。 ストアドプロシージャについてわからない-私はそれをチェックしていません。
チェンジセットは、他の形式-SQL、JSON（XMLだけでなく）でも作成できます。 SQLでのチェンジセットの形成は、別のユーティリティのツールを移行に使用する場合に役立ちます。
3. schemasync
（ http://schemasync.org/ ）データベースの構造を同期するためのツール。 動作するには、pythonとmysqlに対応するインターフェイスが必要です。
liquibaseとの重要な違い：
-schemasyncはchangetsetだけでなく、変更をロールバックできるファイルも作成します（最も重要で最も価値のある利点ですが、私の意見では、同期の前にバックアップする必要がなくなるわけではありません）
-liquibaseを使用すると、変更を取得できるだけでなく、ユーティリティ自体のツールを使用してすぐに移行を開始できます。 キラー機能ではないかもしれませんが、それでも便利で便利です
schemasyncはsqlでのみ動作します-中間のxmlおよび類似物はありません-私はこの長所と短所の両方で自分自身を見ています。
非常に簡潔な構文、最小限の設定。 コメントと自動インクリメント（構成可能）を同期しないようにします-絶対プラス。
使用例：
schemasync mysql://user:pass@dev-host:3306/dev_db mysql://user:pass@prod-host:3306/production_db
4. MAATKITデータ同期
（ http://www.maatkit.org/doc/ ）mk-table-sync-テーブルデータを同期するためのユーティリティ。 maatkitは、元のMySQLに固有ではない機能を提供するMySQLを操作するためのツールのセット全体であることにすぐ言及します。 この製品がPerconaによって作成されたことを考えると、これは驚くべきことではありません。「MySQLを使用して、長い間使用すべきだったものを追加します」というように、すでに製品を見ることに慣れています。
主キーまたは一意のインデックス（一般に正当化される）がある場合にのみ、テーブルで効果的に機能します。
多数のオプションと設定が用意されており、マスター/スレーブ、マスター/マスター構成を同期できます。 自動同期を開始することができますが、主にこれではなく、変更のログを作成する機能に関心があります。 このユーティリティについて別の記事を書くことができると思いますので、設定については詳しく説明しません。本当に多くのオプションがあり、非常に柔軟な同期設定の可能性を開発者に与え、多くのニュアンスを考慮することができるという事実にのみ焦点を当てます。 オリジナルのドキュメント（http://www.maatkit.org/doc/mk-table-sync.html）を読むことは理にかなっています。
使用例：
mk-table-sync --verbose --print --charset=DB_CHARSET, h=host, P=port1, u=user1, p=password1, t=table1, D=db1 h=host2, P=port2, u=user2, p=password2, D=db2 > /__path__/ChangeLogQueries.sql
追加1：
前述のツールには重大な欠点があります。これは、実動サーバーにデプロイする場合はそれほど重要ではありませんが、開発プロセスで常にそれを思い出します-実行速度。 当初、タスクは、チェーン内のサイト間の同期を自動化するメカニズムを構築することでした。「開発者-テストサーバー-ステージ-本番」。 テストサーバーから（上記のチェーンで）開始するのは非常に簡単です-リソースからの時間だけが必要で、負荷は最小限です。 プロセスが夜間にスケジュールに従って自動的に実行される場合、完了までにかかった時間ではなく、負荷を作成して朝までにタスクを完了することが重要です。 同期が定期的である場合、変更リストが過度に大きくなることはなく、負荷は無視できます。 開発者のプラットフォームとテストサーバーの間の同期に関しては、もう1つ注意が必要です。 この場合、1時間かかる同期は常に具体的であり、不便を生じます。 これらの状況と同期の手段5を促しました：
5.「半自動同期」。
上記のユーティリティでは、時間の大部分（完全に少し少ない）が差分リストの形成に占有されています。 次に、スクリプトを適用して違いを解消します-アクションは非常に高速です（これも公理ではありませんが、ほとんどの場合、開発プロセスで）。 これは、差異のリストを手動で作成し、そのアプリケーションのみを自動化できることを示唆しています。 明白な方法は2つだけありました。
a）どの製品にも、データベースを操作する方法があります-人気のあるフレームワークを使用するか、自家製のカーネルを使用するかは関係ありません。 独自のストレージで必要なすべてのリクエストを修正するだけで十分です（たとえば、構造だけが必要な場合-DDL、データも更新および削除する場合）。
b）フレームワーク（およびcms sinがさらに）データベースで動作するクラスのメソッドを拡張する機能を持たず、データベースへのクエリを実行するメソッドにイベントハンドラーもない場合、すべてのリクエストのログを解析できます（このようなログを含める機能を期待します）すべてのターゲットソフトウェア）、このログから必要なアクションのみを記録します。
独自の変更ログの作成を伴うこのような「半自動同期」には存在する権利がありますが、開発者が上記のユーティリティを使用して、同期後にテーブルが実際に一致することを確認することを推奨する必要がありますファクターはデータの同期においてその修正を行いませんでした）。
追加2：
（更新）残念ながら、私が言及したほとんどすべてのツールには重大な欠点があります（そして、間違えても嬉しいでしょうが、反論はありません）-それらはすべて、tcp / ipを介したデータベースへのリモートアクセスを必要とします。 ローカルホストからのみデータベースへのアクセスを許可し、リモートアクセスを禁止することは通常の慣行であると考えると、上記のツールを使用してのみ同期を達成することはできません。
ポート転送を使用した提案されたソリューションを提供してくれたユーザーDarkByteに感謝します-これで問題は解決します。
成功したアプリケーションとバックアップすることを忘れないでください！