同期のためのタイムスタンプカラムの代わりに

Question

私はローカルのmysqlデータベースと実動のmysqlデータベースを持っています。私はローカルで変更を行い、サードパーティのツールを使用して変更をライブサーバーに同期させます。このツールはチェックサム機能を使用して変更された行を識別します。私のDB構造はシンプルで、1つのvarchar200フィールド（主キーとして機能する）とテキストフィールドです。

何千もの行があるため、同期に時間がかかっています。私はタイムスタンプフィールドを追加すると、同期される行を識別するツールのためにチェックサムをすぐに得ることができると考えられます。タイムゾーンの違いにより、タイムスタンプフィールドがローカルサーバーとプロダクトサーバーで異なるため、これによりさらに多くの問題が発生しました。

私は、行が変更されたときに変更される有用なアイデアやタイムスタンプの代替案を探しています。

PS：私はsimilar questionを投稿しましたが、役に立たない回答はありませんでした。私は追加のテーブルに頼るつもりはない。

Answer 1

ヒント：TIMESTAMPデータ型を使用しないでください。DATETIMEを使用してください。それらは同じ種類のデータを保持しますが、TIMESTAMPは行をタッチするたびにに更新されます。その列を設定しなくても、挿入を含めて "now"で更新されます。

これは、TIMESTAMPを使用すると、真に2つのデータベースを真に同期できないことを意味します。その列は常に異なります。 DATETIMEを使用すると、その列のデータを保持できます。

DATETIME列を "now"で更新するようにアプリケーションをコーディングできない場合は、それを実現するトリガーを作成するだけです。

Answer 2

あなたは、いくつかのことを行うことができます：

1. は、ソーステーブルに「汚い」の列を追加します。行が変更されたときに反転し、sync'dを取得したときに元に戻す単一のBITにします。行IDが主キーの場合、これは簡単な挿入です...重複キー更新時
2. すべての時間をGMTとして保存します。タイムゾーンを超えて戦うことはもうありません。とにかく時間が保存されている場合は、これは標準的な練習です。
3. 2台のサーバー間でレプリケーションをセットアップするので、MySQLはコピー/更新を行います。これは正確に設計されたものであり、うまく機能します。

Answer 3

タイムスタンプするのは実際には悪い考えです。クライアントが独自の最新の同期時間を更新すると、多くの行がサーバー上で更新され、これらが見逃されることがあります。サーバー上の行を追加または変更するたびに1ずつ増加するカウンターを使用し、クライアントはそれ自身を更新してカウンターの最新値を取得します。クライアントはカウンタの最後の値を取得しない可能性があります（たとえば、クライアントが更新を要求している間に一部の行が更新されます）が、次の更新時に追いつくことが保証されます