なぜ移行するのですか？

システムバージョンとデータベースのアップグレードにより、テストプロセスがブロックされました。データとシステムバージョンの一貫性を確保するために、パフォーマンステストにこの環境を使用する必要があったため、リーダーと開発者にこの学習の機会なので、ここにプロセス全体を記録します。

使用計画：

ツールとコーディングを組み合わせて、MySQLデータベースをバックアップし、バックアップデータベースをローカルのMySQLデータベースに復元し、サードパーティのツールを使用してデータ移行を完了します。

ツールを使用する：

最初の移行ツール

Microsoft SQL Server Migration Assistant for MySQL：このツールはMicrosoftから推奨されていますが、一部のテーブルデータを完全に移行できないなどの問題もあります。

2番目の移行ツール

Navicat Premium 12：推奨されません、遅く、失敗する傾向があります

3番目の移行ツール

Tapdata：これも優れたサードパーティツールですが、不安定で、メモリ全体がオーバーフローします。基盤となるJavaで記述されています。使用中の問題を解決するには、カスタマーサービスと通信する必要があります。カスタマーサービスはあまり理想的ではありません。

比較ツール

超比較：を使用して結果を比較する

ツールの使用法

最初の移行ツールは

Microsoft SQL Server Migration Assistant for MySQL、このツールはMicrosoftによって作成されており、非常に使いやすく、速度も比較的高速です。

https://www.microsoft.com/en-us/download/details.aspx?id=54257から、をダウンロードしてインストールします。

このツールの使用方法は次のとおりです。具体的な手順は次のとおりです。

ステップ1：移行プロジェクトを作成する

移行するSQLServerデータベースのバージョンを選択する必要があることに注意してください。現在、サポートされているのはSQL Azure、SQL Server 2005、SQL Server 2008、SQL Server 2012、SQLServer2014です。必要なバージョンを選択してください。実際のニーズに応じて、ターゲットデータベースに移行します。

ステップ2：ソースデータベースとターゲットデータベースを接続します

上はソース：MySQL、下はターゲット：SQL Server

ステップ3：移行するデータベースを選択し、移行分析レポートを作成します

このレポートは、移行が必要なデータベース内のすべてのテーブル構造を分析し、実現可能性レポートを生成します

生成されるレポートは次のとおりです。

変換が必要なオブジェクト、テーブルやデータベースの数、変換できないオブジェクトなどの情報を分析します。チェックエラーが発生した場合は、以下に出力されます。

ステップ4：スキーマ、つまりデータベース構造を変換する

移行は2つのステップに分かれています。1。データベース構造を変換します。2。データを移行します。

ステップ5：ソースデータベースがスキーマを変換した後、ターゲットデータベースで同期スキーマ操作を実行することを忘れないでください

そうしないと、変換されたデータベース構造がターゲットデータベースに転送されません。

[同期]をクリックすると、同期レポートも表示されます。

[OK]をクリックすると、実際の同期操作により、変換された構造がターゲットデータベースに同期され、対応するテーブルやその他のオブジェクトが作成されます。同期操作が完了すると、次の出力が出力されます。

ステップ6：構造の同期が完了したら、次のステップはデータ移行操作です

右側にいくつかのタブページがあることがわかります。現在選択されているのはタイプマップで、ソースデータベースとターゲットデータベースのフィールドタイプ間のマッピング関係が一覧表示されます。

異なるデータベース間のデータ型はまだ異なるためです。

[データの移行]をクリックした後、ソースデータベースのパスワードとターゲットデータベースのパスワードの入力を再度確認してから、実際のデータの移行を開始する必要があります。

実行後、完了するのを待つだけで、データ移行の完了のレポートも生成されます。この時点で、データの移行を完了することができます。

2番目の移行ツールは

Navicat Premium 12は、多くのステップがグラフィカルで比較的単純なため、操作が簡単なツールです。

具体的な操作手順は次のとおりです。

MySQL、SqlServer接続を確立し、

MySQL接続をダブルクリックして接続を確立します

次に、navicatの左上隅のツールを選択します

データは自動的にインポートされます

注：ツールは、デフォルト値などの制約を同期しません。ただし、null以外の制約をSqlServerに渡すことができます。

3番目の移行ツール

Tapdata、このツールは永久に無料で使いやすいです。具体的な使用法は次のとおりです。

ステップ1：MySQL接続を構成する

1. Tapdata Cloudの操作背景の左側のメニューバーにある[接続管理]をクリックし、右側の[接続リスト]の右上隅にある[接続の作成]ボタンをクリックして、接続タイプの選択ページを開きます。、次にMySQLを選択します

2.開いた接続情報構成ページで、必要な構成情報を順番に入力します。

[接続名]：接続名を設定します。複数の接続の名前を繰り返すことはできません

[データベースアドレス]：データベースIP/ホスト

[ポート]：データベースポート

[データベース名]：tapdataデータベース接続はデータソースとしてdbを使用します。ここでのdbは、mysqlインスタンスではなく、データベースインスタンス内のデータベースを指します。

【アカウント】：データベースにアクセスできるアカウント

【パスワード】：データベースアカウントに対応するパスワード

【タイムゾーン】：データベースのタイムゾーンがデフォルトで使用されます。タイムゾーンが指定されている場合は、指定されたタイムゾーン設定が使用されます。

手順2：SQLServer接続を構成する

3.最初の手順として、左側のメニューバーの[接続管理]をクリックし、右側の[接続リスト]の右上隅にある[接続の作成]ボタンをクリックして、接続タイプの選択ページを開きます。次に、SQLServerを選択します

4.開いた接続情報構成ページで必要な構成情報を順番に入力し、構成が完了したらテスト接続を保存します。

ステップ3：同期モードを選択します-フル/インクリメンタル/フル+インクリメンタル

Tapdata Cloud操作のバックグラウンドタスク管理ページに入り、[タスクの追加]ボタンをクリックしてタスク設定プロセスに入ります

作成した接続に応じて、リモートエンドとターゲットエンドを選択します。

データ要件に応じて、同期するライブラリとテーブルを選択します。テーブル名を変更する必要がある場合は、ページのテーブル名バッチ変更機能を使用して、ターゲットテーブル名をバッチで設定できます。

上記のオプションを設定したら、次のステップは同期タイプを選択することです。プラットフォームは、完全同期、増分同期、完全+増分同期を提供し、書き込みモードと読み取り数を設定します。

完全+増分同期が選択されている場合、完全なタスクが実行された後、TapdataAgentは自動的に増分同期状態に入ります。この状態で、Tapdata Agentは、ソースエンドのデータ変更（書き込み、更新、削除を含む）を継続的に監視し、これらのデータ変更をターゲットエンドにリアルタイムで書き込みます。

タスク名をクリックしてタスクの詳細ページを開き、タスクの詳細を表示できます。

[タスクモニター]をクリックして、タスク実行の詳細ページを開きます。このページでは、タスクの進行状況やマイルストーンなどの特定の情報を表示できます。

ステップ4：データ検証を実行する

通常、同期が完了した後は、ピットを踏まないようにデータ検証を定期的に行っています。

Tapdataには3つの検証モードがあります。私は通常、最速の高速カウント検証を使用します。他の複雑なパラメーターや条件を設定せずに、検証するテーブルを選択するだけで済みます。シンプルで便利です。

十分ではないと思われる場合は、テーブルの全フィールド値の検証を選択することもできます。検証するテーブルを選択するだけでなく、テーブルごとにインデックスフィールドを設定する必要もあります。

テーブルで完全なフィールド値の検証を実行する場合、高度な検証もサポートされます。高度な検証により、JS検証ロジックを追加し、ソースとターゲットのデータを検証できます。

フィールド値の検証に関連する検証方法もあります。関連するフィールド値の検証を作成する場合、検証するテーブルを選択するだけでなく、テーブルごとにインデックスフィールドを設定する必要があります。

上記は、MySQLデータのSQLServerへのリアルタイム同期の操作共有です。

使用されるSQLテクノロジー

MySQLセクション

ライブラリのすべてのテーブル名をクエリする

sql

select table_name from information_schema.tables where table_schema='数据库名';

データベース内のすべてのテーブル名の列名フィールドの長さを照会します

sql

SELECT TABLE_NAME as '表名', COLUMN_NAME as '列名',COLUMN_COMMENT,DATA_TYPE as '字段类型' ,COLUMN_TYPE as '长度加类型' FROM information_schema.`COLUMNS` where TABLE_SCHEMA='数据库名' order by  TABLE_NAME,COLUMN_NAME

sqlserverの部分

SQLserverは、現在のデータベース内のすべてのテーブル名を照会します

sql

SELECT Name FROM SysObjects Where XType='U' ORDER BY Name;

データベース内の重複データをクエリし、IDでクエリします

sql

SELECT id FROM 数据库名 where id<>'' GROUP BY id HAVING COUNT(*)>1

テーブルの各フィールドのまったく同じ状況を削除し、データを1つだけ残します

sql

-- delete  top(1) from 数据库名 where id =id值

ログを削除

sql

USE [master]
GO
ALTER DATABASE 数据库名 SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE 数据库名 SET RECOVERY SIMPLE   --简单模式
GO
USE 数据库名
GO
DBCC SHRINKFILE (N'数据库名_log' , 2, TRUNCATEONLY)  --设置压缩后的日志大小为2M，可以自行指定
GO
USE [master]
GO
ALTER DATABASE 数据库名 SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE 数据库名 SET RECOVERY FULL  --还原为完全模式
GO

テーブルフィールドを変更する

sql

alter table 数据库名 alter column 字段名	字段类型(长度)

sqlserverの問題を解決します：タイムアウトが期限切れになりました。操作が完了する前にタイムアウトが期限切れになるか、サーバーが応答しませんでした。

1.メニューバーをクリックします：[ツール]->[オプション]

2.スクリプト実行タイムアウトを設定します（必要に応じて、0は制限なしを意味します）

3.リンク文字列の更新時間を設定します（必要に応じて、範囲は1〜65535です）。

Navicatプレミアム16無制限トライアル

bash

@echo off

echo Delete HKEY_CURRENT_USER\Software\PremiumSoft\NavicatPremium\Registration[version and language]
for /f %%i in ('"REG QUERY "HKEY_CURRENT_USER\Software\PremiumSoft\NavicatPremium" /s | findstr /L Registration"') do (
    reg delete %%i /va /f
)
echo.

echo Delete Info folder under HKEY_CURRENT_USER\Software\Classes\CLSID
for /f %%i in ('"REG QUERY "HKEY_CURRENT_USER\Software\Classes\CLSID" /s | findstr /E Info"') do (
    reg delete %%i /va /f
)
echo.

echo Finish

pause

データ移行が成功した後に発生した問題

移行を繰り返し試行すると、一部のテーブルデータが繰り返されるため、重複データを手動で削除する必要があります。
一部のテーブルフィールドタイプは変更され、移行ツールはそれらをSqlServerでサポートされているフィールドタイプに自動的に変換します。これにより、一部のアプリケーションサービスが影響を受け、正常に起動できなくなります。開発部門の同僚は、それらを見つけて正しいタイプに変更する必要があります。
一部のテーブルには主キーとインデックスがない場合があり、手動で追加する必要があります。
テーブルフィールドのタイプとインデックス、主キーの変更、テーブルごとに変更した場合、ワークロードは非常に大きくなります。

最後に書く

移行プロセス全体で合計2週間近くかかりましたが、思ったよりもはるかに難しく、問題も非常に困難でした。データ量が多いと、運用に大きな問題が発生することは間違いありません。データの挑戦。

元のリンク：
https ：//www.cnblogs.com/longronglang/p/16165672.html

この記事がお役に立てば、気に入ってフォローしてください。

プロセス全体が正確であり、MySQLデータをSQLServerに移行するプロセス全体_

なぜ移行するのですか？

使用計画：

ツールを使用する：

最初の移行ツール

2番目の移行ツール

3番目の移行ツール

比較ツール

ツールの使用法

最初の移行ツールは

2番目の移行ツールは

3番目の移行ツール

使用されるSQLテクノロジー

MySQLセクション

sqlserverの部分

データ移行が成功した後に発生した問題

最後に書く

おすすめ