質問

私が働いている会社は、米国の2つのデータベース(1TBが1TBを超える)を持っています - 米国の2、ヨーロッパの2。

4ノード間でデータベースごとに完全なピアツーピアレプリケーションを実行するため、すべてトランザクション(INSERT / UPDATE / DELETE)を取得できます(挿入/更新/削除)、他のノードが収集したデータ(変数待ち時間内)接続は平均約30~40秒)です。

最大データベースは2008年初めから今日のデータを運びます。このデータはすべて、すべてのデータを保持するレポートノードにさらに複製されます。

トランザクションノードで、トランザクションノードでドライブスペースの赤字を削除するためにトランザクションノードでデータを削除する必要があります。したがって、履歴データはレポートノードでのみ利用可能になります。

これを行う最善の方法は何ですか?データは、それがよく分割されている(毎月区画によって、そして毎年別々のファイル/ファイルグループに)分割されているという点で比較的管理可能です。ただし、複製に関与している間にパーティションをドロップできないという問題があり、パーティションの切り替え時の読み取り - これはそのまま使用できません。 (パーティションの切り替え前提条件 - ポイント18 )

完全な生産環境として、再同期を含む複製に影響を与えるものは何も避けようとしています。(大きな距離を超えて再同期するデータ)。

このタスクの実行方法については誰もが良い提案をしていますか?

役に立ちましたか?

解決

だからここからの答えはありませんが、ある程度の議論や考えの後、私は数ヶ月前に計画を思い付きました。

このフォーラムにこの答えを簡潔にします(あなたは私が持っていることに同意するかもしれません。)将来同様の仕事をする必要がある人の誰かが何でも逃した場合に質問を自由に感じてください - この方法は簡単ですが。

そのため、主な関心事は、再送中のノードでの生産トラフィックに大きな影響を与えることなくデータを削除することです。これを行う最も簡単な方法は、そのノードからデータを削除し、そのノードからのデータを削除することですが、他のすべてのものが影響を受けない(レポートノードを含む)。

これを行う最善の方法(パーティションを削除できず、ほとんどの操作も複製できないため、大量のトラフィックと大量の行の変更を作成することはできません)は、新しいSPを作成してパブリケーションを設定することです。この1つのsp。したがって、それはすべてのノードで利用可能になるはずです。重要なビットは、結果ではなくSPの実行を複製するためにレプリケーションを設定することです(ID= 1のDELETEではなくEXEC SP_DELETE呼び出しは、ID= 1は、ID= 2行レベルが変更された場合は削除)。これはあなたの新しい出版物を右クリックして設定されています(トポロジの他のノードを設定する前)>プロパティ>記事>設定>記事のプロパティのボタン>設定されたストアドプロシージャの設定の設定>レプリケート行=実行ストアドプロシージャ。 P2Pトポロジを完成させてください。

しかしMhsqldba、あなたは言っているかもしれません、それはSPを介してすべてのノードで行を別々に削除するつもりです。 - これが、削除のみを実行するようにSPを設定する理由です。

@@ servername= '現在のサーバを'

にしたい場合

削除手順でフォローしてください。

このEXEC呼び出しが削除したくないサーバーでピックアップされると、@@ servernameが選択したサーバーと等しくないので無視されます。

あなたは考えるかもしれません - あなたが興味を持っているサーバーだけでspを作成して実行するだけではありませんか?・これを行うと、レプリケーションは記事(表)行にどのように影響し、実際の変更を複製するかに変更を分解し、実際の変更を複製します.SPのexecが複製されるようにSPを複製する必要があります。結果としての変化よりもむしろ。

これは私の意見/経験におけるイベントの推奨順序です:

  1. @@ servername=希望するサーバー
  2. の場合、削除コードのみを実行することを指定するDELETE CODEでSPを作成します。
  3. セットアップこの1のSPをレプリケートで複製する新しいパブリケーション=記事プロパティ
  4. 内のストアドプロシージャの実行
  5. 希望のサーバーでSPを実行し、何千もの複製された削除コマンドを使用して全体の不動産を停止していないことが
  6. 注意点:

    1. これはまだ面倒な仕事です。この方法を使用することによって、あなたが作業しているものとは別にすべてのサーバーへの効果を減少させました。あなたのためのワークロードを減少させていません、実際にあなたがそれを悪化させたことを確認しました - あなたは各ノードでこの同じspを実行する必要があります(if行があなたがターゲティングしているサーバーに変更されたサーバーに変更された)、あなたが持っている仕事を効果的に増やすつもりです。影響を与える必要があるサーバーの数によって他のすべてのノードに最小限の影響を及ぼしますが、(もちろん取り組んでいるノードから失敗した場合は失敗しました。)
    2. この方法を使用すると、あなたのノード間の不整合を生み出しました - あなたが仕事を必要とするすべてのノードで同じ操作を実行する前にあなたが削除しているデータが変更されることができないことを実際には必要であることを確認してください。 1ノードで削除した行がエステートの残りの部分内で変更された場合は、一貫性エラーになります。
    3. あなたが作業しているノードで削除を実行するのにかかる時間の中で、通常の複製が必要な期間の遅れになると予想される可能性があります(削除をバッチ処理することを強くお勧めします) - それが必要です。操作が完了すると、削除操作のロックが解放された後に通常の複製がバックアップされるまで、ノードをアクションに戻すことはできません。高度なレイテンシの行を複製している場合は、プッシュの代わりにプルエージェントを使用してチェックアウトすることを真剣にお勧めします。
    4. DELETEを使用するよりもSP内のデータを移動するためのより良い方法があります - レプリケーションに関与していない別のテーブルに移動してから「新しい」テーブルをドロップするか、または逆のデータを削除してください。削除する金額より小さく、新しいテーブルに保存したいデータを移動するには、古いテーブルをドロップしてから、新しいテーブルの名前を変更します。これらの視点からのアドバイスがたくさんあります - 私は環境で働いています。それは概念を宣伝するよりも削除のために戦うのが簡単でした

何人かの人員が理解できないので、痛みを伴うが基本的な方法を説明しています。

免責事項:上記の全ては危険です。適切なものなしで急いで行われた場合は、レプリケーショントポロジ、あなたの会社のデータ、おそらくあなたの雇用を真剣に台無しにすることができます。上記の方法を受け取り、あなた自身のBattleplanを開発してください - 概念、テストテスト、再テストを証明するためのテスト環境の作成この作業を軽く受けないでください。十分に考慮してあなたはあなたの仕事を達成するでしょう - しかし、それは数金曜日の午後に、いくつかの昼食器の後に行う価値がありません。それを正しくしなさい、一度それをします(あなたができる限り実際のテストのために)、正しくそれをしなさい。

私はこれが他の誰かに役立ちます願っています。 - 私はこの答えが欲しいならば、私が検索したことがあるものとしてこのビットを追加しています:

ピアツーピアレプリケーショントポロジから大量のデータを削除する

ライセンス: CC-BY-SA帰属
所属していません dba.stackexchange
scroll top