Tair (Redis® OSS-Compatible):インスタンス間の片方向移行

移行方法の比較

¹ 互換性の問題を避けるため、移行元と移行先で同じデータベースバージョンを使用することを推奨します。

² 標準アーキテクチャのインスタンスからクラスターまたは読み書き分離アーキテクチャのインスタンスに移行する前に、これらのアーキテクチャのコマンド制限をご確認ください。

DTS のデータ移行方法

DTS は 2 つの移行タイプをサポートしています。移行元データベースを停止せずに移行タスクを設定する際に、両方を選択できます。

• [フル移行 + 増分移行] (デフォルト)：ネイティブの Redis SYNC/PSYNC ロジックを使用して、メモリスナップショットから移行先にデータを書き込み、その後、増分更新をリアルタイムで同期します。フル移行は無料で、増分移行は期間に応じて課金されます。

• [フルデータ移行]：SCAN コマンドを使用して、移行元データベース全体を走査します。このタイプの移行中は、データの不整合を引き起こす可能性があるため、移行元への書き込みは行わないでください。

前提条件

開始する前に、以下を確認してください。

• 移行先の Tair (Redis OSS-compatible) インスタンスが存在すること。

• 移行先インスタンスの合計メモリが、移行元インスタンスで現在 使用している 容量よりも大きいこと (少なくとも 10% 多い容量)。たとえば、移行元が 10 GB を使用している場合、移行先には少なくとも 11 GB の合計メモリが必要です。移行先のメモリが不足すると、データの不整合やタスクの失敗につながります。

• 移行先インスタンスでは、透過的データ暗号化 (TDE) は[無効]です。DTS は、TDE が有効化されたインスタンスへの移行をサポートしていません。

• 移行先インスタンスで Tair (Redis OSS-compatible) 2.8 が実行されていないこと。DTS は 2.8 インスタンスをサポートしていません。

制限事項

• 移行タスクの実行中に、移行元または移行先データベースのスケーリング、インスタンスタイプの変更、またはエンドポイントの変更を行わないでください。これらの操作はタスクが失敗する原因となり、再設定が必要になります。

• 移行プロセスは両方のインスタンスでリソースを消費するため、オフピーク時に実行してください。

• 事前チェックでは、移行先データベースの削除ポリシーが [noeviction] に設定されていることを確認します。 Tair (Redis OSS 互換) のデフォルトの削除ポリシーは volatile-lru です。 volatile-lru では、移行先のメモリが不足した場合、データはサイレントに削除され、不整合が発生します。 代わりに noeviction を設定すると、メモリが不足した場合に書き込みは失敗します (タスクも失敗します) が、データがサイレントに削除されることはありません。 詳細については、「Redis のデータ削除ポリシー」をご参照ください。

• 移行完了後、移行先インスタンスのインスタンス ID とエンドポイントは、移行元インスタンスのものとは異なります。クライアント設定を更新して、移行先インスタンスのエンドポイントを使用するようにしてください。

• Tair の永続メモリ最適化インスタンスは、Redis オープンソース版インスタンスにインプレースアップグレードできません。インスタンスタイプを切り替えたい場合は、Redis オープンソース版インスタンスを作成し、DTS を使用してデータを移行してください。

移行タスクの設定

よくある質問

接続テストが失敗するのはなぜですか？

以下を確認してください。

• アカウントまたはパスワードが正しくありません。Redis パスワードの形式は user:password です。詳細については、「インスタンスのログオン方法」をご参照ください。

• 移行元データベースがオンプレミスのデータセンターまたはサードパーティのクラウドにある場合、ネットワークファイアウォールが DTS をブロックしている可能性があります。お使いのリージョンの DTS サーバーの IP アドレスをファイアウォールのホワイトリストに追加してください。手順については、「DTS サーバーの CIDR ブロックをホワイトリストに追加する」をご参照ください。

移行タスクが失敗するのはなぜですか？

• 移行中に移行元または移行先インスタンスのスケーリング、インスタンスタイプの変更、またはエンドポイントの変更を行うと、タスクが失敗します。操作完了後にタスクを再設定してください。

• 移行先インスタンスまたはクラスターのシャードでメモリ不足 (OOM エラー) が発生すると、タスクは失敗します。開始前に移行先に十分なメモリがあることを確認してください。

• 移行先インスタンスで TDE が有効になっている場合、DTS 移行はサポートされていません。

データの不整合が発生するのはなぜですか？

• TTL キー：移行元のキーの一部に有効期限 (TTL) ポリシーがある場合、期限切れのキーが迅速に削除されないことがあるため、移行先のキーが少なくなることがあります。

• リストオブジェクト：DTS は PSYNC または SYNC を使用する際、移行先に既存のリストデータに対して FLUSH を実行しないため、重複したエントリが発生する可能性があります。

• フル移行の再試行：フル移行中にネットワークが中断された場合、DTS は再試行し、同じ名前のキーを上書きします。再試行中に移行元がキーを削除した場合、その削除は同期されないため、移行先が一時的に移行元よりデータが多くなることがあります。

Tair (Redis OSS-compatible) 2.8 インスタンスを選択できないのはなぜですか？

DTS は Tair (Redis OSS-compatible) 2.8 インスタンスをサポートしていません。

事前チェックでエビクションポリシーが noeviction に設定されていることを確認するのはなぜですか？

Tair (Redis OSS-compatible) のデフォルトのエビクションポリシー (maxmemory-policy) は volatile-lru です。移行先でメモリが不足すると、このポリシーがデータのエビクションをトリガーし、タスクを失敗させることなく移行元と移行先の間で不整合を引き起こします。ポリシーを noeviction に設定すると、サイレントなデータ損失を防ぎます。メモリが不足すると書き込みが失敗し、タスクも失敗しますが、データはエビクションされません。詳細については、「Redis のデータエビクションポリシー」をご参照ください。

移行元データベースに DTS_REDIS_TIMESTAMP_HEARTBEAT キーが存在するのはなぜですか？

移行と同期の品質を監視するため、DTS は移行元データベースに DTS_REDIS_TIMESTAMP_HEARTBEAT というプレフィックスを持つキーを挿入し、更新タイムスタンプを追跡します。クラスターアーキテクチャの場合、DTS はこのキーを各シャードに挿入します。DTS は移行中にこのキーを除外し、タスクが終了するとキーは自動的に期限切れになります。

増分移行でサポートされているコマンドは何ですか？

以下のコマンドがサポートされています。

• APPEND

• BITOP, BLPOP, BRPOP, BRPOPLPUSH

• DECR, DECRBY, DEL

• EVAL, EVALSHA, EXEC, EXPIRE, EXPIREAT

• FLUSHALL, FLUSHDB

• GEOADD, GETSET

• HDEL, HINCRBY, HINCRBYFLOAT, HMSET, HSET, HSETNX

• INCR, INCRBY, INCRBYFLOAT

• LINSERT, LPOP, LPUSH, LPUSHX, LREM, LSET, LTRIM

• MOVE, MSET, MSETNX, MULTI

• PERSIST, PEXPIRE, PEXPIREAT, PFADD, PFMERGE, PSETEX, PUBLISH

• RENAME, RENAMENX, RESTORE, RPOP, RPOPLPUSH, RPUSH, RPUSHX

• SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, SUNIONSTORE

• ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, ZREMRANGEBYSCORE

• XADD, XCLAIM, XDEL, XAUTOCLAIM, XGROUP CREATECONSUMER, XTRIM

注：EVAL または EVALSHA によって呼び出される Lua スクリプトについて、移行先は明示的な実行結果を返さないため、DTS はスクリプトが移行先で正常に実行されたかどうかを確認できません。

関連ドキュメント

既存のインスタンスに移行するのではなく、Tair (Redis OSS-compatible) インスタンスの全データを新しいインスタンスにクローンしたい場合は、バックアップと復元機能を使用してください。

• バックアップセットからの復元

• ポイントインタイムへの復元