1か月前、Yandex.Moneyで、OracleからPostgreSQLへのユーザープロファイルサービスの転送が完了しました。 そのため、大量のデータを損失なく移行し、それらを使用してサービスを停止するための実証済みのソリューションができました。

カットの下で、それがどのように起こったのか、移行のためにSymmetricDSを選んだ理由、そして「手動」の努力なしではまだできない理由について詳しく説明します。 また、移行用の補助コードに関するいくつかの開発を共有します。

ソリューションの最初の移行と実行では、ユーザープロファイルを提供するサービスを選択しました。 このプロファイルには、支払い履歴、お気に入り、リマインダー、およびその他の類似のものが含まれます。これらはすべて重要ですが、システムが機能するために重要ではありません。 ロジックが組み込まれていないデータベースがあるため、データとシーケンスを新しいプラットフォームに転送するだけで済みました。

したがって、3か月後、ユーザープロファイルはOracleなしでも機能するはずです。

他のプロジェクトの差し迫ったリリースに関連して、彼らは3ヶ月で移転を完了することを決めました。 移行チームは4人で構成されていましたが、シニア開発者とDBAスペシャリストでした。 小さなチームが短時間で対処できるように、彼らはプロジェクトの最も自動化されたソリューションを探しました。データ移行コードを記述せずに、データベーススキーマを手動で組み立てるなどです。 データベースには約50のテーブルが含まれているため、人為的なエラーの可能性は手動変換中に特に高くなります。

通常、このような移行は、サービスを停止した状態で（数時間後に）実行されます。 しかし、Yandex.Moneyでは、支払いは24時間行われるため、内部の「最適化」のためにシステムを停止することは不可能でした。 実際、このコンポーネントの場合、ビジネスはデータの損失なしに1〜2分間停止することに同意しました。

完璧なツールを見つける

プロジェクトの四半期ごとの期間は、独自の準自転車の発明の余地を残しませんでした。 したがって、ブレーンストーミングにより、移行に適した製品のリストを収集して削除しました。

1. Oracle GoldenGate-これは同じ特効薬のように見えるかもしれません。 少なくとも価格に慣れるまで。

   
   
   
   
   
   
   

2. SymmetricDS-スキーマの移行があり、OracleマスターノードにPostgreSQLノードを登録するときに作成または更新されます。 BASH、Java、またはSQLを使用して、アップロードまたはダウンロード中にデータを変換することができます。

   
   
   
   
   
   
   

3. 完全変換 -スキームとデータを移行できますが、カスタマイズの可能性は限られており、変更可能なトランスフォーマー（移行中にデータを変更するためのコード）はありません。

   
   
   
   
   
   
   

4. OracleからPostgreSQLへの移行 -スキーマ、データ、外部キー、インデックスを転送します。 半自動レプリケーション、変換なし。ただし、異なるデータベースのタイプの対応を設定できます。

   
   
   
   
   
   
   

5. ESF Database Migration Toolkit -OracleからPostgreSQLへの移行と同じすべてを移行します。 データはバッチモードで送信されるため、複数のストリームに移行する可能性はありません。

   
   
   
   
   
   
   

6. Ora2Pg-スキーム、データ、外部キー、インデックスの転送、複数のフローへの移行が可能です。 マイナスの点：blob / clobタイプ（約200レコード/秒）のテーブルの低速転送、トランスフォーマーなし。

   
   
   
   
   
   
   
7. SQLDataツール -スキーマのみが移行され、カスタマイズオプションが制限されます。

市場に出回っている残りの製品は、開発者によってすでに放棄されているか、コミュニティで開発されたサポートがありません。

その結果、データ移行のためにデータベーススキーマとSymmetricDSを転送するためにOra2Pgが選択されました。 一般的に、後者はデータ転送よりも異なるDBMSの同期を目的としています。 しかし、この場合、サービスを停止せずに移行を提供できました。

移行のための千の小さなこと

移行が運用ベースのコピーにロールされたとき、移行ソリューションに一連の「機能」と奇妙な点が見つかりました。 PostgreSQLは、Oracleで問題なく渡された一部のクエリを正しく実行しませんでした。 たとえば、 SELECT *によりエラーが発生し、データベース依存サービス全体がシャットダウンしました。 一般に、そのようなリクエストは悪い形式であり、実際には異なるものであり、許可された例としてこれらを単に引用しました。 これはJavaドライバーの問題であることが判明したため、プロジェクトの時点では、問題のあるクエリを使用しない方が簡単でした。 このバグは後で修正されました。

AutoCommit-OFFフラグが設定されている場合、トランザクションに問題がありました。 PostgreSQLでは、トランザクションが実行される前に開かれていない場合、コードがクラッシュしました。 Oracleの動作は異なります。トランザクションはロールバックされるか、同じ実行スレッドに入ったコードで完了しました。 PostgreSQLのソリューションは、すべてのデータ変更要求に対して明確に開かれたトランザクションをチェックするコードを記述することです。

クエリを実行する際、ユーザープロファイルサービスは表示された値のソート順（ORDER BY）を指定しませんでした。これは、Oracleでは符号がないために時系列で出力が行われるためです。 そしてこれについては、クエリの結果を異なる方法で表示するPostgreSQLに滑り込みました-ORDER BYがどこにでもあるようにコードを組み合わせました。

興味深いニュアンスは、元のOracleデータベースとPostgreSQLに転送されたインスタンスの両方のデータを変更する複合トランザクションにありました。 両方のデータベースで同じ値を持つために、私たちのチームは特別なトランザクションマネージャーを開発しました。 彼は、両方のDBMSでトランザクションを同期してオープンおよびクローズしました。 そのようなトランザクションでエラーが発生した場合は、すでに手動で解決する必要がありました。

そして離れて行く

50のテーブルの事前承認済みリストによると、データの移行は段階的に行われました。 データベース内の各テーブルのレベルで切り替えを行うことにしました。これにより、高い柔軟性とプロセスの分解を実現できました。 つまり、データ転送後の特定の時点で、テーブルに特別なフラグが設定され、それに応じてYa.MoneyサービスがPostgreSQLのデータインスタンスに切り替えました。

Oracle-PostgreSQLの移行を成功させるには、面倒なことを忘れないように事前に計画することが重要です。 このような計画がありましたが、ここではネタバレです。

移行中、50のテーブルの一部はOracleで機能し、もう1つはPostgreSQLで機能しました。 これがSymmetricDSが役立ち、OracleからPostgreSQLにデータを移行したため、移行されたテーブルと古いスキームに従って機能するロジックの両方の一貫性を確保しました。

サービスでのデータ転送後、特定のテーブルごとに「PostgreSQLで動作」チェックボックスが設定され、クエリは新しいDBMSに切り替わりました。 最初に、スイッチはdevスタンドでチェックされ、次に受け入れスタンドでチェックされました。 問題がなければ、本番に切り替えて、Oracleのテーブルの名前を変更します（古いテーブルがまだ使用されているかどうかを確認します）。

考え方は図にあります。PostgreSQLで複製データベースを作成した後、サービスに新しいdbフラグが設定され、その後、すべての呼び出しが新しいデータベースに送られます。

しかし、最も難しいことは、適切な切り替えのタイミングを選択することでした。 実際、テーブルの重要度と複雑さに応じて、3つの移行オプションがありました。

1. テーブル全体を転送し、続いて切り替えます。 このオプションは、リクエストの一部が失われる可能性がある場合に適していました（ユーザーにもう一度ボタンを押すように求められるか、操作の自動継続が機能します）。

   
   
   
   
   
   
   

2. データセンターのレベル （DC、合計で2つあります）。 重要なテーブルを転送する方法。最初のデータセンターを最初にPostgreSQLに転送し、オンにするプロセスで2番目のデータセンターをオフにします（Oracleから）。 開始時に、OracleとPostgreSQLの停止は並行して機能する可能性があります。そのため、同期とデータスイッチングのメカニズムが役立ちました。 サービスの作業にダウンタイムはありませんでした。

   
   
   
   
   
   
   
3. 「残留スクイーズ」の方法による 。 2つのインスタンスを残します。切り替えのための遅延リクエストを処理するOracleと、新しいPostgreSQLです。 新しいタスクは新しいデータベースで処理され、古いタスクは残りのOracleでの実行後に削除されました。 そのため、ベースのキューが移動しました-自動支払い、リマインダーなど

いくつかの困難がありました。 PostgreSQLのデータベーススキーマの初期形成中に、コンバーターは100％の既製バージョンを生成しませんでした。これは一般に予想されていました。 いくつかの種類の列を手動で変更し、シーケンスを修正し、ダイアグラムをテーブルとインデックスに分割する必要がありました。 しかし、後者はすでに秩序と一般的な美学のためのものです。

少し後で、SymmetricDSが150 GBを超えるテーブルを同期しないことが判明しました。 したがって、コードに座って、そのようなケースを移植するための回避策を作成する必要がありました。

ただし、ここでも特効薬は機能しませんでした。 SymmetricDSは、テーブルの合計サイズを超えたためにCLOB \ BLOBフィールドを転送しなかったため、手動の移行キューを作成する必要がありました。 OracleからPostgreSQLへの移行によりパフォーマンスが急激に低下した非常に珍しいケースに直面しました。 個々のケースを手動で分解する以外に何もありませんでした。 たとえば、1つのテーブルの場合、別のテーブルのCLOBフィールドを選択してSSDに転送し、必要な場合にのみこのフィールドを読み取る必要がありました。

古いデータベースインスタンスと新しいデータベースインスタンスを同時にアクティブに保つ必要があったため、重複キーをPostgreSQLに転送および転送しようとしないように、新しいインスタンスのシーケンス用に予約を作成しました。

この図は、1000キーの古いデータと新しいデータの間に「インデント」があるPostgreSQLの新しいテーブルの概略図を示しています。

つまり、テーブルの最後のキーが100だった場合、転送中にこの値にさらに1000が追加されたため、SymmetricDSは新しいデータを上書きせずにキー101、102およびその他すべてを自由に同期できます。

仕上げリボン

計画四半期中、私たちの小さなチームはテーブルの80％をPostgreSQLに移行しました。 残りの20％は、大きなCLOB \ BLOBフィールドを持つプレキャストテーブルを含む、大きなテーブル（平均150 GB以上）です。 これはすべて、次の1.5か月間、手動で完了する必要がありました。 それでも、SymmetricDSとOra2Pgの組み合わせは、タスクの条件に必要なほとんどの日常的な作業を行いました。 私たちの開発チームは、このプロジェクトのために内部の「レーキ」貯金箱をほぼ補充しました。その一部は、記事の公開時点でおそらく舞台裏に残されていました。

しかし、Yandex.Moneyは、サンクトペテルブルクで開催されるPG Day'17カンファレンスの着陸をすでに準備しています。 拡張レポートにアクセスして、難しい質問を準備してください。

ただし、ここで最も熱烈なトピックをコメントで取り上げることを提案します。 移行の経験について、そしておそらく、私たちが見落としていたことについて読むのは非常に興味深いです。

Yandex.Moneyリポジトリには、記事に記載されているソリューションのコードがいくつかあります。

• トランザクションマネージャーのソース

  
  
  
  
  
  
  
• トランザクション検証クラスコード。