14

フィールドに行の挿入/更新のタイムスタンプを記録するテーブルが 1 つあります。

このテーブルのデータを別の db サーバーの別のテーブルと同期したいと考えています。2 つの db サーバーは接続されておらず、同期は一方向 (マスター/スレーブ) です。テーブル トリガーの使用は適していません

私のワークフロー:

  • グローバルな last_sync_date パラメータを使用し、変更/挿入されたレコードに対してテーブル Master をクエリします
  • 結果の行をxmlに出力します
  • xml を解析し、更新と挿入を使用してテーブル スレーブを更新します

マスター テーブルの削除されたレコードを処理する場合、問題の複雑さが増します。削除されたレコードをキャッチするには、以前に挿入されたレコードのログ テーブルを維持し、sql "NOT IN" を使用する必要があると思います。これは、大規模なデータセットを扱う場合にパフォーマンスの問題になります。

このシナリオを扱う別のワークフローは何ですか?

4

10 に答える 10

9

トランザクション メッセージ キューが必要なようです。

これがどのように機能するかは簡単です。マスター データベースを更新すると、任意の数のキューに送信できるメッセージ ブローカー (更新内容に関係なく) にメッセージを送信できます。各スレーブデータベースは独自のキューを持つことができ、キューの順序が保持されるため、プロセスは最終的に正しく同期する必要があります (皮肉なことに、これはほとんどの RDBMS が内部でレプリケーションを行う方法の一種です)。

メッセージ キューは、一種の SCM 変更リストまたはパッチ リスト データベースと考えてください。つまり、ほとんどの場合、マスターに送信された同じ (またはほぼ同じ) SQL ステートメントは、最終的に他のデータベースに複製される必要があります。ほとんどのメッセージ キューは持続性とトランザクションをサポートしているため、メッセージが失われる心配はありません。

タグを付けたので、特におよび/またはを確認することをお勧めします。

あなたのコメントに基づいて：

ところでNOT IN、パフォーマンスの問題であるというあなたの懸念は、多くの回避策があるため、あまり良いものではありませんが、DB 固有のこと (トリガーやレプリケーションなど) を実行したくないことを考えると、メッセージ キューが最善の選択肢であると感じています。

編集 - 非 MQ ルート

この質問をするのに苦労したので、引き続きお手伝いします。メッセージ キューのほかに、以前に試みたように、ある種の XML ファイルを実行できます。スキーマで必要な重要な機能は、マスター データベースの CREATE TIMESTAMP 列です。これにより、システムの稼働中にバッチ処理を実行できます (そうしないと、システムを停止する必要があります)。このルートに行く場合SELECT * WHERE CREATE_TIME < ?は、現在の時間よりも短くしたいと思うでしょう。基本的に、スナップショットで行を取得するだけです。

inner joining削除のために他のデータベースで、IDテーブルで行を削除しようとしていますが、 !=（つまり、の代わりに JOINS を使用できます slow NOT IN）。ids幸いなことに、すべてのfor deleteだけが必要で、他の列は必要ありません。更新タイム スタンプ列に基づいてデルタを使用できるその他の列 (更新用、別名挿入用)。

于 2013-03-13T01:38:57.237 に答える
5

解決策がわかりません。しかし、これらのリンクが役立つことを願っています。

http://knowledgebase.apexsql.com/2007/09/how-to-synchronize-data-between.htm

http://www.codeproject.com/Tips/348386/Copy-Synchronize-Table-Data-between-databases

于 2013-03-05T12:17:12.240 に答える
2

最後の更新/挿入/削除時刻を示す TIMESTAMP 列を追加してみませんか? 次に、削除された列を追加します-つまり。行を実際にすぐに削除するのではなく、行を削除済みとしてマークします。削除アクションをエクスポートした後、それを削除します。

既存のアプリでスキーマの使用法を変更できない場合:

トリガーをまったく使用できませんか？挿入/更新/削除のたびに入力され、次に生成されるxmlエクスポートファイルのコンテンツを構成する2番目の(「非表示」)テーブルはどうですか? これは一般的な概念です: 履歴 (または「ログ」) テーブル: エクスポート マーカーとして使用できる独自の進行中の ID 列があります。

于 2013-03-06T00:41:07.867 に答える
2

Oracle GoldenGate をご覧ください。

Oracle GoldenGate は、異種データ環境でのデータのレプリケーションを可能にする包括的なソフトウェア パッケージです。この製品セットは、高可用性ソリューション、リアルタイム データ統合、トランザクション変更データ キャプチャ、データ レプリケーション、変換、運用および分析エンタープライズ システム間の検証を可能にします。

SymmetricDS :

SymmetricDS は、マルチマスター データベース レプリケーション、フィルタリングされた同期、または異種環境でのネットワーク全体の変換のためのオープン ソース ソフトウェアです。一方向または双方向の非同期データ レプリケーションで複数のサブスクライバーをサポートします。

水仙レプリケーター：

水仙のレプリケーターは、さまざまなデータベース サーバー間でデータの同期、データの移行、およびデータのバックアップを行うための Java ツールです。

于 2013-03-09T08:30:16.700 に答える
1

同期する必要があるテーブルの履歴テーブルを作成し (基本的にはそのテーブルの複製で、おそらくいくつかのフィールドを追加します)、アクティブなテーブルで何かが挿入/更新/削除されるたびに行全体を挿入します。

履歴テーブルの追加フィールドに基づいてデータをスレーブ マシンに同期する Spring バッチ ジョブを作成する

お役に立てれば..

于 2013-03-11T11:08:30.197 に答える
1

データベースにトランザクション ダンプ ログがある場合は、それを送信するだけです。

MySQL で可能であり、PostgreSQL で可能であるはずです。

于 2013-03-17T21:52:47.260 に答える
1

現在のワークフロー内で削除を許可するための潜在的なオプション:

トリガーの制限がデータベース間の参照を伴うトリガーに限定されている場合、現在のワークフロー内で考えられる解決策は、マスター データベースにヘルパー テーブルを作成して、削除された行の一意の識別子 (または任意の一意のキー削除した行を最も効率的に削除できます)。

これらの ID は、削除時にマスター テーブルのトリガーによって挿入される必要があります。

挿入/更新と同じメカニズムを使用して、挿入と更新に続くタスクを作成します。現在のワークフローで指摘したように、ヘルパー テーブルを xml にエクスポートできます。

このタスクは単にスレーブ テーブルから行を削除し、タスクの完了後にヘルパー テーブルからすべてのデータを削除します。監査証跡がないため、これをトラブルシューティングできるように、タスクからのエラーをログに記録します。

于 2013-03-11T21:39:31.147 に答える
0

私は別のコメントに同意します-これにはトリガーの使用が必要です。別のテーブルにSQLステートメントの履歴を保持する必要があると思います。2008拡張イベントの使用に関するこの回答を参照してください...次に、SQL全体を取得し、結果クエリを履歴テーブルに保存できます。mysqlクエリまたはmssqlクエリとして保存するかどうかはあなた次第です。

于 2013-03-09T01:39:49.197 に答える
0

これが私の見解です。本当にこれに対処する必要がありますか？スレーブはレポート目的のためのものだと思います。だから私が尋ねる質問は、それがどのくらい最新であるべきかということです? データが 1 日経過しても問題ありませんか? 毎晩のリフレッシュを計画していますか?

その場合は、このオンライン同期プロセスを忘れて、完全なテーブルをダウンロードしてください。それをmysqlに送り、バッチロードします。処理時間は、思ったよりもずっと速いかもしれません。

于 2013-03-12T00:51:16.443 に答える