翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 大規模な MySQL データベースと MariaDB データベースを移行するためのベストプラクティス
<a name="best-practices"></a>

移行オプションごとにリストアップされているツール固有のベストプラクティスに加えて、以下の一般的なベストプラクティスを確認してください。これらのベストプラクティスは、選択したツールに関係なく、大規模なマルチテラバイト MySQL および MariaDB データベースを移行する場合に適用されます。
+ ソースデータベースと宛先データベースにバックアップを取得および復元するための十分なスペースがあることを確認します。
+ 移行が完了するまで、ターゲットデータベースインスタンスにセカンダリインデックスを作成しないでください。セカンダリインデックスは、インポート中のメンテナンスオーバーヘッドを増加させ、インポートプロセスを遅らせる可能性があります。
+ マルチスレッドアプローチを使用する場合は、適切な数のスレッドを選択します。エクスポートでは、CPU コアごとに 1 つのスレッドを使用することをお勧めします。インポートでは、2 つの CPU コアごとに 1 つのスレッドを使用することをお勧めします。
+ データダンプは、ミッションクリティカルな本番環境の一部であるアクティブなデータベースサーバーから実行されることがよくあります。データダンプがパフォーマンスに大きく影響し、お使いの環境で許容できない場合は、次のいずれかを検討してください。
  + ソースサーバーにレプリカがある場合、レプリカの 1 つからデータをダンプできます。
  + ソースサーバーが通常のバックアップ手順の対象である場合:
    + バックアップ形式がターゲットデータベースへの直接インポートに適している場合は、バックアップデータをインポートプロセスの入力として使用します。
    + バックアップ形式がターゲットデータベースへの直接インポートに適していない場合は、バックアップを使用して一時データベースをプロビジョニングし、そこからデータをダンプします。
  + レプリカとバックアップが利用できない場合:
    + 本番トラフィックが最も低いオフピークの時間帯にダンプを実行します。
    + ダンプオペレーションの同時実行数を減らして、サーバーが本番トラフィックを処理するのに十分な予備容量を確保します。
+ ユーザーが作成したデータベースのダンプのみを作成します。
+ ターゲットデータベースでユーザーを再作成し、アクセス許可を設定します。詳細については、「[Amazon RDS での Identity And Access Management](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.html)」、「[Amazon Aurora での Identity And Access Management](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.html)」、または「[Amazon EC2 の Identity And Access Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-iam.html)」を参照してください。
+ 複数の独立したデータベースで構成される大規模なデータベースサーバーを移行する場合は、データベースごとに個別のインスタンスを作成します。これにより、データベースをより効率的に管理し、リソースのプロビジョニングを改善し、個別のコンピューティングリソースによってデータベースのパフォーマンスを向上させることができます。