記事のディレクトリ
（1）単一のマシンから分散型へのデータベースの課題と応答
（1）データベース解凍ソリューション
1：スタンドアロンハードウェアのアップグレード、垂直拡張
2：アプリケーションレベルの最適化、データベースアクセスプレッシャーの軽減
3：キャッシュの導入、データ検索エンジンの追加、データベース読み取りプレッシャーの軽減
4：データベースデータとアクセスは複数のデータベースに分割され、水平方向に拡張
（2）水平および垂直データ分割の分析
定義：
垂直分割：データベース内の異なるビジネスユニットのデータを異なるデータベースに分割します。ビジネス分割によると、ユーザーデータベース、注文データベースの
水平分割など、特定のデータの独立性があります。同じビジネスユニットが特定のに従って分割されます。ルールデータは複数のデータベースに分割されます。規則によれば、水平分割の結合はビジネスデータの合計を構成します
垂直パーティションの分析
1.スタンドアロンマシンのACID保証が破られています。データが複数のマシンに到着すると、元々トランザクションを通じて単一のマシンで実行されていた処理ロジックが大きく影響を受けます。私たちが直面する選択は、元の単一マシントランザクションを放棄するか、実装を変更するか、分散トランザクションを導入するかです。
2.データがすでに2つのデータベースにある可能性があるため、一部の結合操作はより困難になります。そのため、データベース自体の結合は簡単に使用できず、それを解決するにはアプリケーションまたはその他の方法が必要です。・制約するために外部キーに依存するシナリオが影響を受けます。
レベル分割問題
1の分析：ACIDも壊れている可能性があります。
2：結合操作が影響を受ける可能性もあります。
3：制約するために外部キーに依存するシナリオは影響を及ぼします。
4：単一ライブラリの自動インクリメントシーケンスによって生成された一意のIDが影響を受けます。
5：単一の論理テーブルのクエリはクロスデータベースである必要があります。
（2）分散トランザクション
（1）分散トランザクションのモデルと仕様
1：X / OPen組織、つまりOpen Groupは、分散トランザクション仕様を提案します-XA
2：X / Open組織は分散トランザクション処理モデルを定義します-X / OPen DTPモデル
3：DTPモデルの3つのコンポーネント： AP、RM、TM
トランザクション：トランザクションは、論理的にアトミックな複数の独立したコンピューティングタスクで構成される完全な作業単位です。
グローバルトランザクション：一度に複数のRMリソースマネージャーを操作するトランザクションはグローバルトランザクションです
ブランチトランザクション：グローバルトランザクションでは、各リソースマネージャーには独自の独立したタスクがあります。これらのタスクのコレクションは、リソースマネージャーのブランチタスクです。
制御スレッド：ワーカースレッド、主にAP、TM、およびRMに関連付けられたスレッド、つまりトランザクションコンテキストを表すために使用されます。つまり、グローバルトランザクションとブランチトランザクションの間の関係を識別するために使用されるスレッドです。
AP：アプリケーションプログラム（AP）。これは、DTPモデルを使用するプログラムとして理解できるアプリケーションプログラムです。トランザクションの境界を定義し、トランザクションを構成するアプリケーションの特定の操作を定義します。
RM：リソースマネージャー（RM）、リソースマネージャーは、DBMSシステムまたはメッセージサーバー管理システムとして理解できます。アプリケーションはリソースマネージャーを介してリソースを制御し、リソースはXAによって定義されたインターフェイスを実装する必要があります。リソースマネージャーは、共有リソースの保存をサポートします。
TM：トランザクションマネージャー™、トランザクションマネージャー、トランザクションの調整と管理、APアプリケーションプログラミングインターフェイスの提供、およびリソースマネージャーの管理を担当します。トランザクションマネージャーは、トランザクションに識別子を割り当て、その進行状況を監視し、トランザクションの完了と失敗を処理する責任があります。トランザクションブランチ識別子（XIDと呼ばれる）は、RM内のグローバルトランザクションと特定のブランチを識別するためにTMによって指定されます。これは、ログインTMとログインRMの間の相関マークです。2フェーズコミットまたはロールバックでは、システムの起動時に再同期操作（resync（resync）とも呼ばれます）を実行するため、または管理者が必要に応じてヒューリスティック操作（手動介入とも呼ばれる）を実行できるようにするためにXIDが必要です。
注：
APとRMが必要であり、TMは私たちによる追加の紹介です。TMを導入する理由は、分散システムでは、2台のマシンの理論が一貫した状態に達することができず、単一の調整ポイントを導入する必要があるためです。トランザクションマネージャーは、グローバルトランザクションを制御し、トランザクションのライフサイクルを管理し、リソースを調整します。
（2）2PCを2段階で提出する
2フェーズコミットプロトコル、つまり2PC、2フェーズコミットプロトコル。2フェーズコミットと呼ばれる理由は、単一データベースのトランザクションコミット方法に関連しています。単一のデータベースで関連するデータ操作を完了した後、直接送信またはロールバックします。分散システムでは、送信前に準備フェーズが追加されるため、2フェーズコミットと呼ばれます。
準備の
第1段階、コミットまたはロールバックの第2段階
実際には、TMトランザクションマネージャー自体の安定性と可用性の影響、およびネットワーク通信で発生する可能性のある問題のために、状況ははるかに複雑になります。さらに、トランザクションマネージャは複数のリソース間で調整を行うため、それ自体で多くのロギング作業を実行する必要があります。ネットワーク上の対話の数の増加とトランザクションマネージャーの導入のオーバーヘッドは、2フェーズコミットプロトコルを使用した分散トランザクションのオーバーヘッドを増加させる2つの側面です。
したがって、垂直分割または水平分割を実行した後、2段階の分散トランザクションを導入する必要があるかどうかを判断する必要があり、必要な場合にのみ使用することをお勧めします。
（3）CAPとBASE
CAP理論は、2000年7月のPODC会議でEricBrewerによって提案されました。CAPの意味は次のとおりです。
一貫性：すべてのノードが同時に同じデータを表示します。つまり、すべてのノードが同時に同じデータを表示します。これはデータの一貫性（Cで示されます）です。つまり、データが正常に書き込まれると、すべてのノードに新しいデータが同時に表示されます。
可用性：すべてのリクエストが成功したか失敗したかについての応答を受け取ることを保証します。これはデータの可用性（Aで示されます）です。ここでのポイントは、システムが応答する必要があるということです。
パーティショントレランス：システムの一部で任意のメッセージの損失または障害が発生した場合でも、システムは動作を継続します。システムに問題があったり、メッセージが失われたりしても、システムは動作を継続できます。これはパーティショントレランス（Рで示される）と呼ばれ、システムの一部に問題が発生した場合でもシステムが機能し続けることができることを意味します。
ただし、分散システムでは、上記の3つの項目を同時に満たすことはできません。そのうちの2つを選択して改善することができますが、もう1つは損失を被ります。次に、システムを設計および計量するときに、実際にはCA、AP、またはCPを選択します。
CAを選択し、パーティションの許容範囲を放棄し、一貫性と可用性を強化します。これは実際には、従来のスタンドアロンデータベースの選択です。
APを選択し、一貫性を放棄し、パーティションの許容範囲と可用性を追求します。これは、多くのNoSQLシステムなど、多くの分散システムの設計上の選択です。
CPを選択し、可用性を放棄し、一貫性とパーティションの許容範囲を追求します。このオプションでの可用性は比較的低く、ネットワークの問題によりシステム全体が直接使用できなくなります。
分散システムでは、通常、整合性（AP）を犠牲にして、可用性とパーティションの許容範囲を強化することを選択します。もちろん、ここで話しているのは、一貫性を気にしないということではなく、最初にPを満たし、次にCの問題を解決する方法を検討するということです。
BASEモデルを見てみましょう。BASEの意味は次のとおりです。
基本的に利用可能：基本的に利用可能で、パーティションの障害は許可されます。
ソフト状態：ソフト状態。同期していない期間を受け入れます。
結果整合性：結果整合性。最終データの状態に整合性を持たせるため。
分散システムのCAPでAとPを選択する場合、Cの場合、採用する方法と戦略は、最終的な一貫性を確保することです。つまり、データが変更された直後にすべてのノードが一貫していることを保証するわけではありませんが、最終的に一貫しています。大規模なWebサイトでは、スケーラビリティと可用性をより適切に維持するために、通常、強い整合性は選択されませんが、最終的には整合性のある戦略が採用されます。
（3）Paxos契約
（1）基礎知識
1：Paxosプロトコルを使用するための前提条件があります。つまり、ビザンチンの一般的な問題はありません。ビザンチン将軍問題は、信頼できる通信環境を保証する方法がない問題です。Paxosの前提は、信頼できる通信環境があることです。つまり、情報が正確であり、改ざんされていないということです。
2：Paxosアルゴリズムを提案するプロセスは、Paxosと呼ばれるギリシャの都市国家を仮想化し、議会を通じた決議によってPaxosアルゴリズムを導入することです。
3：Paxosアルゴリズムは、最初にメンバーの役割を提案者、承認者、学習者に分割し、メンバーは複数の役割を持つことができます
提案者：提案を提案する人が提案の役割です。
アクセプター：提案を受けた後の判断の役割。承認者は、提案を受け取った後に提案を受け入れるかどうかを選択します。提案が承認者の過半数によって受け入れられた場合、提案は承認されます（選択）。
学習者：承認された請求書のみを「学習」できます。これは、通過した請求書を監視する役割に相当します。
4：関連用語
提案：提案者によって提案され、承認者によって承認または拒否された提案。
値：解決策、提案の内容、各提案は{数値、解決策}のペアで構成されます。
5：決議（価値）は、提案者によって提案された後にのみ承認することができます（未承認の決議は「提案」と呼ばれます）。
Paxosアルゴリズムの実装では、一度に1つの値のみを承認（選択）できます。学習者は、承認された（選択された）値のみを取得できます。
（2）基本-Paxosの基本プロセス
1：準備
提案者は、この提案者によって以前に提案された提案番号よりも大きい番号Nの提案を提出します。アクセプターに受信を要求するQuornm。
2：
Nがこのアクペターが受け取った以前の提案番号よりも大きい場合は約束し、それ以外の場合は拒否します。
3：
承認が過半数に達した場合、提案者は提案番号と内容を含む承認リクエストを発行します
4：このアクセプターがこの期間中にNより大きい提案を持っていない場合は、この提案の内容を受け入れます。それ以外の場合は無視します。
詳細なPaxosアルゴリズムプロセス：
https ：//zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
説明：
1：Paxosの基本原則は、少数派が多数派に従うことです
。2：Paxosでは、複数の人が同時に提案を提出すると、衝突が失敗する可能性があるため、提出する前に両方の当事者が提案の数を増やす必要があります。プロセス。ただし、再送信にはまだ数の競合があるため、両方の当事者が送信する数を増やす必要があります。これにより、デッドロックが発生します。解決策は、クラスター全体にリーダーを設定することであり、そのような競合を回避できるように、すべての提案がリーダーによって提起されます。これは実際に提案の作業を単一のポイントに変えており、発生する新しい問題は、問題が発生した場合にこのリーダーにどのように対処するかであり、リーダーを選択する必要があります。
（4）シーケンスの問題と複数のマシンの処理
水平サブデータベースに変更する場合は、単一のデータベース内の元のシーケンスおよび自己インクリメントIDメソッドを変更する必要があります。おなじみのOracleではSequenceのサポートが提供され、MySQLではAuto Incrementフィールドのサポートが提供され、Idを繰り返さずに自己インクリメントシーケンスを簡単に実装できます。サブデータベースとサブテーブルの後、これが問題になりました。この問題は、次の2つの方向から考えて解決することができます。（一意性と継続性）
ldの一意性のみを考慮する場合は、UUID生成方法を参照するか、独自の方法に従って各シード（IP、MAC、マシン名、時間、ローカルカウンター、その他の要因などのさまざまなディメンションの識別）を使用できます。ビジネスの状況。一意のldを生成します。このようにして生成されたldの一意性は保証されますが、分散システム全体の連続性は良くありません。
ここで言及されている連続性とは、分散環境全体で生成されたIDの連続性を指します。スタンドアロン環境では、実際にはこのタスクを完了するのは1つのポイントです。分散システムでは、独立したシステムを使用してこのタスクを完了することができます。
（5）複数のマシンのデータクエリ問題の分析
（1）結合の問題
データベースを分割した後、以前の結合操作の一部を変更する必要があります。結合が必要なデータがすでに複数のデータベースに分散している場合は、データベース間の結合操作を完了する必要があります。これはさらに面倒です。解決策は次のとおりです。以下：
1：クエリXXX前XXに基づいて、次にXXに基づいXXに、アプリケーションレベルで多段階の操作に参加する最初のクエリの元の関節のクエリを変換し、そして。。。
2：冗長な情報を適切に追加します。つまり、複数のテーブルでクエリする必要のあるフィールド情報を1つのテーブルに配置し、冗長なフィールドを作成し、過剰な複数テーブルの共同クエリを減らします
。3：外部システム（検索エンジンなど）を使用していくつかを解決します。クロスライブラリの問題
（2）外部キーの制約
外部キー制約の問題は解決がより難しく、前の機能を完了するためにデータベース自体に完全に依存することはできません。サブデータベースの後の単一データベースに外部キー制約を作成する場合、サブデータベースの後の各単一データベースのデータはまとまりがある必要があります。そうでない場合は、アプリケーション層の判断とフォールトトレランスにのみ依存できます。 。
（3）複合クエリ
このシナリオも、以前のデータベース間結合とは異なります。データベース間結合は、異なる論理テーブル間の結合です。データベースが分割された後、これらの結合は複数のデータベースにまたがる必要がある場合があり、結合されたクエリは、論理テーブル。ただし、物理的に複数のデータベースと複数のテーブルに分割されているため、データの結合クエリが生成されます。
考慮事項：
1：並べ替え：複数のデータソースがクエリされた後、アプリケーション層で並べ替えます
2：関数処理：Max、Min、Sum、Countなどの関数を使用して、複数のデータソースの値に対して対応する関数処理を実行します。
3：平均値を計算する複数のデータソースからクエリを実行する場合は、SQLを変更して合計とカウントをクエリし、複数のデータソースから合計とカウントを合計した後に平均値を計算する必要があります。これは注意が必要なことです。 to。ローカル。
4：ソートされていないページング。これは、同じステップサイズの複数のデータソースでのページング処理であるか、同じ比率でのページング処理であるかなど、特定の実装戦略によって異なります。同じステップ長は、ページの各ページで、
異なるデータソースからのレコードの数が同じであることを意味します。同じ比率は、デシベルマザーでは、同じデータソースからのデータの数がこのデータソースを占めることを意味します。条件の総数の割合は同じです。
（6）データアクセス層の設計と実装
データアクセス層は、アプリケーションのデータ読み取り/書き込みアクセスを容易にする抽象化層であり、さまざまなアプリケーションで一般的に使用されるデータベースへのアクセスの問題を解決します。分散システムでは、データアクセス層を分散データアクセス層とも呼びます。略してデータ層と呼ばれることもあります。
（1）外部データアクセス層を提供する方法
最初の方法は、ユーザーに独自のAPIを提供することですが、この方法はお勧めできません。その汎用性は非常に低く、汎用性はないとさえ言えます。一般的に、このメソッドは関数の実現を容易にするために使用されます。または、このメソッドは、いくつかの一般的なインターフェイスメソッドに対して比較的大きな変更と拡張があります。
2番目の方法は普遍的な方法です。Javaアプリケーションでは、データベースは通常JDBCを介して接続されます。データレイヤー自体をJDBC実装として使用できます。つまり、JDBCインターフェイスをアプリケーションに公開します。現時点では、アプリケーションのコストは非常に低く、JDBCドライバーはリモートデータベースのを使用します。方法は同じで、移行コストも非常に低くなります。
ORMまたはORMのようなインターフェースに基づく別の方法がありますが、この方法は上記の2つの方法の中間であると言えます。効率的で便利なアプリケーション開発のために、
iBatis、hibernate、Spring JDBCなどのデータベースを使用する場合はORMまたはORMのようなフレームワークが一般的に使用されます。アプリケーションが使用するORMフレームワークにレイヤーをラップして、データレイヤーを実装できます。元のフレームワークの機能はまだ外の世界に公開されています。このアプローチは、一部の機能では比較的低コストであり、互換性に一定の利点があります。たとえば、元のシステムがiBatisを使用している場合、iBatisのパッケージはアプリケーションに対してより透過的です。
さらに、ORM / ORMのようなフレームワークを使用すると、フレームワーク自体の制限により問題が発生する可能性があります。たとえば、iBatisを使用しているときにSQLを動的に変更することはより困難です。これは、JDBCドライバーに直接基づく実装ではそれほど難しくありません。
（2）データレイヤープロセスの順序に従ってデータレイヤーの設計を確認します
[SQL解析段階での処理]
1：SQLのサポートの程度と、すべてのSQLをサポートする必要があるかどうかは、特定のシナリオによって異なります
。2：サポートされるSQLの方言の数、および異なる部分に対してサポートする必要のある量標準SQLを超えるベンダー、これは特定のシナリオに従って決定する必要があります
3：SQL解析のプロセスで、解析キャッシュは解析速度を向上させることができます
。4：SQL解析を通じて、次のようなSQLの重要な情報を取得できます。テーブル名、フィールド、場所の条件など。データレイヤーでは、実行されたSQLに従って操作テーブルを取得し、パラメーターとルールに従ってターゲットデータソース接続を決定することが非常に重要です。
【ルール処理段階】
1：ルールとして固定ハッシュアルゴリズムを使用します。
一般的な方法は、テーブルの特定のフィールド（ユーザーID）に基づいてモジュラスを取得し、データをさまざまなデータベースやテーブルに分散することです。この方法は、複雑なビジネスのシステムに適しておらず、後で拡張する必要がある場合、固定ビジネスで拡張の頻度が低いシステムに適しています。
2：コンシステントハッシュアルゴリズムを使用します。
コンシステントハッシュによってもたらされる最大の変化は、ノードに対応するハッシュ値が離散的ではなく範囲になることです。コンシステントハッシュ法では、非常に大きなハッシュ値の範囲全体を定義してから、この範囲を既存のノードに割り当てます。ノードが参加すると、新しいノードが元のノードのハッシュ値の一部を担当します。ノードが終了すると、このノードによって最初に管理されていたハッシュ値が次のノードによって管理されます。ハッシュ値の範囲が0〜100で、合計4つのノードがあるとすると、それらが管理する範囲は[0,25）、[25,50）、[50,75）、および[75,100]です。2番目のノードが終了すると、残りのノードの管理範囲は[0,25）、[25,75）、[75,100]になります。1番目と4番目のノードで管理されているデータは効果がないことがわかります。元々3番目のノードによって管理されていたデータは影響を与えず、2番目のノードが担当するデータを引き継ぐだけで済みます。たとえば、2番目と3番目のノードの間にノードを追加する場合、これらの5つのノードによって管理される範囲は[0,25）、[25,50）、[50,63）、[63、 75）、[75,100]、1番目、2番目、4番目のノードは影響を受けず、3番目のノードのデータの一部は影響を受けず、データの別の部分を追加する必要があることがわかります。管理するノード。
問題：
新しいノードが追加されると、新しいノードを除いて1つのノードのみが影響を受けます。この新しいノードと影響を受けるノードの負荷は、他のノードよりも大幅に低くなります。1つのノードが削減されると、減算されたノードを除きます。 、影響を受けるのは1つのノードのみであり、元のノードと減算されたノードの作業を行う必要があり、圧力は他のノードよりも明らかに高くなります。これは、各ノードの負荷分散を維持するために、ノードの数を2倍にするか、ノードの半分を差し引く必要があるようです。この場合、コンシステントハッシュの利点は明らかではありません。
3：コンシステントハッシュ法への仮想ノードの改善
上記の問題に対処するために、仮想ノードの概念を紹介します。つまり、4つの物理ノードが多数の仮想ノードになる可能性があり、各仮想ノードは連続ハッシュリング上のセグメントをサポートします。このとき、物理ノードを追加すると、それに応じて多くの仮想ノードが追加されます。これらの新しい仮想ノードは、ハッシュリング全体に比較的均等に挿入されるため、既存の物理ノードのプレッシャーを十分に共有できます。﹔ 1つの物理ノードが削減されると、対応する多くの仮想ノードに障害が発生します。このように、前の仮想ノードの作業を引き受ける仮想ノードが残りますが、物理ノードの場合、増加する負荷は比較的バランスが取れています。したがって、1つの物理ノードは多数の仮想ノードに対応し、同じ物理ノードの仮想ノードは、ノードを追加または削減する際の不均衡な負荷の問題を解決するために、可能な限り均等に分散されます。
[SQLを書き換える]
1：異なるデータベースのテーブル名、単一データベース後のテーブル名標準はサブテーブル
2：サブデータベースサブテーブル後のインデックス名の変更
（7）読み書きの分離に対する課題と対応
（1はじめに
上の図は、読み取りと書き込みの分離が使用される一般的なアプリケーションシナリオを示しています。読み取りと書き込みを分離することで、マスターライブラリ（マスター）の読み取り圧力を共有できます。データ複製の問題があります。つまり、メインデータベースのデータをスレーブデータベース（スレーブ）にコピーします。
（2）データ構造は同じで、複数のスレーブライブラリが1つのマスターライブラリに対応しています。
1：マスタースレーブデプロイメント構造と比較して、データベースシステムが提供する同期メカニズムを使用する方が簡単です。たとえば、MySQLのレプリケーションはレプリケーションの問題を解決でき、遅延は比較的小さくなります。
2：上図のようなメインライブラリが、複合構造の比較的複雑な展開方法である場合、どのように対処しますか？
アプリケーションは、データレイヤーを介してデータベースにアクセスし、メッセージシステムを介してデータベースの更新に関するメッセージ通知を送信します。データ同期サーバーは、メッセージ通知を受信した後、データをコピーします。サブデータベースルール構成は、データが読み取られ、データ同期サーバーがサブデータベースを更新するときに、データレイヤーにサブデータベースルールを通知する役割を果たします。データ同期サーバーとDBメインデータベース間の相互作用は、主にコンテンツを取得するために変更または新しく追加されたデータ主キーに基づいており、行レプリケーション方式が採用されています。
これは洗練されていない方法であると言えますが、問題を解決することができます。より洗練された方法は、データベースログに基づいてデータを複製することです。
（3）メイン/スタンバイデータベースサブデータベースのさまざまな方法でのデータレプリケーション
データベースレプリケーションは、読み取りと書き込みの分離においてより重要なタスクです。一般に、対称コピー、つまりミラーリングが実行されますが、非対称にコピーされるシーンもあります。ここでの非対称レプリケーションとは、ソースデータとターゲットデータがミラーリングされていないことを意味し、ソースデータベースとターゲットデータベースが異なる実装であることも意味します。現時点では、単にデータをコピーすることはできません。データの配布を制御し、実際のビジネスシナリオのためにいくつかの処理を行う必要があります。
（4）データ変更プラットフォームの導入
他のデータベースへのコピーはデータ変更のシナリオであり、検索エンジンインデックスの構築、キャッシュの無効化など、データの変更も考慮する他のシナリオがあります。データの変更を管理および制御するための共通のプラットフォームを構築することを検討できます。
（5）スムーズなデータ移行を実現する方法
データベースをスムーズに移行するための最大の課題は、移行プロセス中にデータが変更されることです。検討できる解決策は、データ移行の開始時に増分ログを記録し、移行が終了した後に増分変更を処理することです。最後に、移行するデータの書き込みを一時停止して、増分ログが確実に処理されるようにしてから、ルールを切り替え、すべての書き込みを解放して、移行作業を完了することができます。
参照プロセスの手順：
1：まず、拡張を開始し、データベースデータの変更の増分ログの記録を開始します。
この時点では、増分ログと新しいデータベーステーブルの両方がまだ空です。idを使用してレコードを識別し、vを使用してバージョン番号を識別します（これはデータベーステーブルのビジネスフィールドではありませんが、スムーズな移行プロセスを明確にするために追加したフラグです）。
2：次に、データが新しいデータベーステーブルにコピーされ始め、更新も行われます。
ご覧のとおり、id = 1およびid = 3のデータはすでに新しいデータベーステーブルにありますが、id = 1のレコードバージョンは古く、id = 3のレコードバージョンはすでに新しいものです。ソースデータベーステーブルのすべてのデータを新しいデータベーステーブルにコピーすると、コピープロセス中に変更が発生するため、新しいデータベーステーブルのデータがすべて最新のデータではない場合があります。
3：完全な移行が終了すると、増分ログのデータも移行します
増分ログを処理すると新しい増分ログが入力されるため、このアプローチでは、新しいデータベーステーブルのデータとソースデータベーステーブルのデータの整合性が保証されないことがわかります。これは段階的な収束プロセスです。 。。
4：次にデータを比較します。現時点では、新しいデータベースデータとソースデータベースデータに違いがある可能性がありますので、記録してください。
5：次に、ソースデータベースに移行するデータの書き込み操作を停止し、増分ログを処理して、新しいデータベーステーブルのデータを新しいものにします。
6：最後にルーティングルールを更新し、すべての新しいデータを新しいデータベーステーブルに対して読み取りまたは書き込み、移行プロセス全体を完了します。