DynomiteデータベースをRedisEnterpriseActive-Activeデータベースに移行する方法

この記事のパートI「DynomiteデータベースをRedisEnterpriseActive-Activeデータベースに移行する理由」では、DynomiteとRedisEnterpriseのアーキテクチャと機能を比較しました。 Redis Enterpriseが、機能が豊富で管理しやすい方法でRedis Enterpriseを地理的に分散し、同時書き込み間の競合を心配しないようにする方法を示しました。

パートIIでは、DynomiteからRedisEnterpriseに移行するために利用できる移行オプションについて説明します。

以降、Redis Enterpriseの自己管理型オファリングは「RedisEnterpriseソフトウェア」と呼ばれ、管理対象オファリングは「RedisEnterpriseCloud」または「クラウドサブスクリプション」と呼ばれることに注意してください。

Dynomiteデータベースの移行

実用的になって、2種類の移行を実行する方法を見てみましょう。

RedisEnterpriseのインポート/エクスポート機能を使用した移行
アクティブ-パッシブとも呼ばれるRedisEnterpriseのReplicaOf機能を使用した移行

説明のために、2つのデータセンター（dc-aとdc-b）にまたがるダイノマイトクラスターがあると仮定します。各データセンターには1つのラックがあり、各ラックは2つのノードで構成されており、その間にデータセットが分散されています。

DynomiteデータベースをRedisEnterpriseActive-Activeデータベースに移行する方法

Dynomiteのアーキテクチャの説明を思い出すと、各Dynomiteラックに完全なデータセットが含まれていることがわかります。

したがって、インポート/エクスポートまたはアクティブ-パッシブのどちらであっても、移行の範囲をDynomiteセットアップ内の単一のラックに制限できます。

Rack-1-dc-aを選び、その2つのノードのIPが次のようになっていると仮定します。

a1：10.0.0.1
a2：10.0.0.2

わかりやすくするために、Dynomiteセットアップのyaml構成は次のとおりです。

#a1
dyn_o_mite:
  datacenter: dc-a
  dyn_listen: 10.0.0.1:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.3:7379:rack1:dc-a:4294967294
  - 10.0.0.4:7379:rack1:dc-b:4294967294
  - 10.0.0.2:7379:rack1:dc-b:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 2147483647
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

#a2
dyn_o_mite:
  datacenter: dc-a
  dyn_listen: 10.0.0.3:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.1:7379:rack1:dc-a:2147483647
  - 10.0.0.4:7379:rack1:dc-b:4294967294
  - 10.0.0.2:7379:rack1:dc-b:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 4294967294
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

#b1
dyn_o_mite:
  datacenter: dc-b
  dyn_listen: 10.0.0.2:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.4:7379:rack1:dc-b:4294967294
  - 10.0.0.1:7379:rack1:dc-a:4294967294
  - 10.0.0.3:7379:rack1:dc-a:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 2147483647
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

#b2
dyn_o_mite:
  datacenter: dc-b
  dyn_listen: 10.0.0.4:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.2:7379:rack1:dc-b:2147483647
  - 10.0.0.1:7379:rack1:dc-a:4294967294
  - 10.0.0.3:7379:rack1:dc-a:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 4294967294
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

このチュートリアルのテストに使用されたこの構成とセットアップに関するいくつかの所見：

Ubuntu18.04を実行している4つのGCPVM。
VMは、複数のリージョンにまたがる同じVPCに存在します。
Dynomiteがデータの複製にこれらのポート（yaml構成の「dyn_port」）を使用するため、ポート7379および7380を開きました。
Redis OSSはポート6379の各ノードで実行されています–yaml構成の「サーバー」を参照してください。
Dynomiteはポート8379でクライアントのリクエストをリッスンします（例：redis-cli -h 10.0.0.1 -p 8379）–yaml構成の「リッスン」を参照してください。

セットアップを理解し、移行に使用するラックを決定したので、RedisEnterpriseデータベースを作成しましょう。

RedisEnterpriseActive-Activeデータベースを作成する

この記事の目的は、クラスターのセットアップ方法やデータベースの作成方法を説明することではないため、以下のドキュメントを参照して、Active-Activeデータベースを稼働させてください。

Redisエンタープライズソフトウェアクラスター
クラウドサブスクリプション
ソフトウェアデータベースの作成
ソフトウェアアクティブ-アクティブデータベースの作成
クラウドデータベースの作成

2つの移行シナリオをテストするために、2つのRedisエンタープライズソフトウェアクラスターにまたがるアクティブ-アクティブデータベースを作成しました。1つはヨーロッパに、もう1つは米国にあります。各クラスターはUbuntu18.04を実行する3つのVMで構成されています。 Active-Activeを使用せずにデータベースを作成する場合、この記事で特に指定されていない限り、移行手順は同じになることに注意してください。

最初のタイプの移行を進めましょう。

インポート/エクスポート機能を使用した移行

Redis OSSは、Redisデータベースバックアップファイル（RDB）と呼ばれる永続性オプションを提供します。これは、指定された間隔で、またはSAVEまたはBGSAVEコマンドによってトリガーされたときに、データセットのポイントインタイムスナップショットを実行します。

これらのスナップショットは、.rdbファイル（以降、RDBファイルと呼びます）に保存されます。それらをDynomiteサーバーからエクスポートし、RedisEnterpriseデータベースにインポートします。このソリューションでは、デルタ移行は不可能であり、データのサイズによってはインポートに時間がかかる場合があることに注意してください。

重要：Redis Enterpriseの非地理分散データベースとアクティブ-アクティブデータベースには大きな違いがあります：

非地理分散データベース：RDBファイルをインポートすると、既存のデータベースコンテンツがすべて消去されます。
アクティブ-アクティブデータベース：RDBファイルをインポートして、既存のデータセットにマージできます。これは、インポート前およびインポート中に、アクティブ-アクティブデータベースへの書き込みトラフィックの送信を開始できることを意味します。注意してください– Dynomiteにすでに存在するActive-Activeデータベースにキーを書き込んでいる場合、その後のインポートで新しい値が古い値で上書きされる可能性があります！これには慎重な計画が必要です。

RDBファイルを使用してDynomiteからRedisEnterpriseにデータを移行する方法は次のとおりです。

Dynomiteデータベースのトラフィックを停止し、移行を慎重に計画していて、Active-Activeデータベースを使用している場合は、RedisEnterpriseデータベースにカットオーバーします。
各ノードのデータ（この場合はa1とa2）をRDBファイルとしてエクスポートします。
Redis Enterpriseクラスターにアクセスできる場所（Google Cloud Storageバケット、AWS S3バケット、FTPサーバーなど）にRDBファイルをアップロードします
RDBファイルをRedisEnterpriseデータベースにインポートします。
RedisEnterpriseデータベースに切り替わる。

上記の手順を詳しく見てみましょう。

オプション：各ノードでRedisOSS構成ファイルを編集します

Dynomiteノードで実行されているRedisOSSインスタンスの構成ファイルは、「apt-get」を使用してインストールした場合はデフォルトで/ etc / redisにあり、RedisOSSを自分でビルドした場合はRedisフォルダーにあります。このファイルは「redis.conf」と呼ばれます。

お気に入りのテキストエディタでこのファイルを開き、「dbfilename」ディレクティブを検索します。

などの各ノードのファイル名を変更します

ノード1の「dump1.rdb」
node2の「dump2.rdb」。

これにより、RDBファイルを外部ストレージにエクスポートするときに同じ名前が付けられなくなります。必要に応じて、これをスキップして、スナップショットを作成した後で名前を変更できます。

オプションで、次のこともできます。

「dir」ディレクティブを使用して、RDBファイルが保存されるディレクトリを変更します。
スナップショットの間隔を変更するか、自動スナップショットを無効にします。このチュートリアルでは、SAVE Redisコマンドを使用してスナップショットをトリガーします。これにより、トラフィックを停止した後、データセット全体を確実にダンプできます。

Redis OSS構成ファイルを編集した後、変更が考慮されるようにRedisOSSサーバーを再起動する必要があることに注意してください。

データをダンプする

ここで、ポート8379を介してDynomiteデータベースに入るトラフィックを停止します。ここでも、Active-Activeデータベースにインポートしていて、インポート中に誤って上書きされるリスクを回避するように慎重に移行を計画している場合は、トラフィックを次のようにカットできます。アクティブ-アクティブデータベース。

redis-cliを起動します。 Dynomiteのリスニングポートであるポート8379は使用しないでください。代わりにポート6379を使用してください。これは、SAVEコマンドをサポートしていないDynomiteクラスターではなく、ノードで実行されているRedisOSSインスタンスに接続する必要があるためです。コマンドライン引数なしでredis-cliを実行できます。

各ノードで、DBSIZEコマンドを実行します。 RedisOSSの各インスタンスに保存されているキーの数を取得します。合計は、Dynomiteデータベース内のキーの数である必要があります。

#a1
127.0.0.1:6379> dbsize
(integer) 1323

#a2
127.0.0.1:6379> dbsize
(integer) 1371

SAVEコマンドを実行し、RDBファイルが/ var / lib / redis、または指定した任意のディレクトリに作成されていることを確認します。

2つのダンプファイルを外部ストレージにエクスポートします

これで、2つのRDBファイルを外部ストレージにエクスポートする準備が整いました。

このチュートリアルでは、ファイルをGoogleCloudのCloudStorageにエクスポートしますが、FTPサーバー、別のクラウドサービスプロバイダーストレージソリューション、RedisEnterpriseクラスターからアクセス可能な外部ディスクなどの他の外部ストレージオプションを使用することもできます。これらのオプションの詳細については、以下をご覧ください。

Redisエンタープライズソフトウェア
Redisエンタープライズクラウド

Google Cloudで、私は以下を作成しました：

JSONキーを作成したサービスアカウント。
ストレージレガシーオブジェクトリーダーのアクセス許可をサービスアカウントに割り当てたクラウドストレージバケット。

次に、ノードごとに、次のコマンドを実行します。

gsutil cp path_to_dump_file gs://your_bucket

これで、GoogleCloudバケットに2つのRDBファイルが表示されます。

これで、それらをActive-Activeデータベースにインポートする準備が整いました。

ダンプファイルをRedisEnterpriseデータベースにインポートする

Redis Enterprise UIにログインし、アクティブ-アクティブデータベースを選択します。このチュートリアルのように、複数のクラスターにまたがるRedis Enterprise Active-Activeデータベースを作成した場合は、任意のクラスターを介してUIに接続できます。このチュートリアルでは、ヨーロッパ（EU）クラスターを使用します。

Cloud Active-Activeデータベースを使用している場合は、CloudUIに接続してデータベースを選択するだけです。

データベースの構成ページに移動して、[インポート]ボタンをクリックしてみましょう。適切なストレージタイプを選択します。この場合、これはGoogleCloudStorageになります。

これで、次のような2つのRDBファイルのクラウドストレージパスを追加できます。

/helene-test/dump1.rdb
/helene-test/dump2.rdb

次の情報も追加する必要があります：

クライアントID
クライアントのメール
秘密鍵ID
秘密鍵

この情報は、GoogleCloudServiceアカウントのキーを作成するときにダウンロードしたJSONキーファイルにあります。

秘密鍵はJSONファイルで奇妙にフォーマットされていることに注意してください。引用符と改行があります。 Redis Enterprise UIが受け入れる方法ですばやくフォーマットするには、Pythonインタープリターを起動して印刷するだけです。

print(WHOLE_COPIED_KEY)

これで、次のインポート構成ができました。

[インポート]をクリックして、データベースのサイズに応じてインポートが完了するのを待ちます。

データベースとカットオーバーを確認します

redis-cliを使用して、RedisEnterpriseデータベースのエンドポイントに接続します。いくつかのキーを読み、DBSIZEコマンドを実行して、キーの総数が正しいことを確認してください。

redis-12000.internal.helene-eu-cluster.demo.redislabs.com:12000> dbsize
(integer) 2694

アクティブ-アクティブジオ複製も確認することを忘れないでください！他のクラスタのデータベースエンドポイント（ここでは米国のエンドポイント）に接続し、取得したキーの数を確認するだけです。

これで移行は終了です。まだ行っていない場合は、データベースへのトラフィックを削減できます。

ReplicaOf機能を使用した移行

それでは、継続的な移行を実行しましょう。

Redis Enterpriseの機能「ReplicaOf」（RedisクラウドUIではアクティブ-パッシブとも呼ばれます）を使用すると、2つのRedisデータベース間でデータを継続的に複製できます。主な利点は、最初の同期が行われた後にデルタを複製することです。これは、アプリケーション側のダウンタイムがほとんど観察されないことを意味します。

手順は次のとおりです。

DynomiteデータベースとActive-Activeデータベースの間にReplicaOfリンクを確立します
最初の同期が完了するまで待ちます
Dynomiteデータベースのトラフィックを停止します
デルタが複製されるまで待ちます
データベース間のReplicaOfリンクを削除します
アクティブ-アクティブデータベースへの切り替え

ReplicaOfは、アクティブ-パッシブの方法で使用することを目的としています。つまり、ターゲットはパッシブであると見なされ、ターゲットが完全に再同期されるように許容される必要があります（ターゲットデータベースのフラッシュ+ソースデータベースからの同期）。

移行を開始する前に、いくつかのセキュリティの側面について説明しましょう。

DynomiteセットアップでのRedisOSSのセキュリティ構成

まず、Dynomiteラックが存在するネットワーク用に6379ポートのカスタムTCPのインバウンドルールを追加する必要があります。

次に、両方のDynomiteノードのRedisOSS構成ファイルを更新する必要があります。デフォルトでは、RedisはIPv4およびIPv6（使用可能な場合）のループバックインターフェイスアドレスでのみリッスンします。これは、RedisOSSが実行されているのと同じホストからのクライアント接続のみを受け入れることができることを意味します。 Redis OSSがRedisEnterpriseクラスターホストからの接続をリッスンできるように、RedisOSSの「bind」ディレクティブを更新する必要があります。

これを行うには2つの方法があります：

Redis OSSに、ピアリングされたVPC内のマシンからの接続のみをリッスンさせる-推奨され、より安全です
すべてのホストがRedisOSSにアクセスできるようにする–特にDynomiteはデータベースパスワードをサポートしていないため、安全ではありません

これら2つのオプションについて詳しく説明しましょう。

オプション1-VPCピアリングあり

最初のオプションは、Dynomiteラックが存在するVPCをRedisEnterpriseクラスターが存在するVPCとピアリングすることです。私たちのように、アクティブ-アクティブデータベースを作成した場合、それはどのクラスターにも存在できることに注意してください。以前と同様に、デモンストレーションにはヨーロッパ（EU）クラスターを使用します。

ネットワークをピアリングしたら、redis.confファイルの「bind」ディレクティブを編集する必要があります。デフォルトのループバックインターフェイスアドレスの後に、DynomiteマシンのプライベートIPを追加します。

ラック内のすべてのノードに対してこれを実行すると、それだけです。 RedisOSSインスタンスを再起動することを忘れないでください。

オプション2–VPCピアリングなし

ネットワークをピアリングできない、またはピアリングしたくない場合は、各ノードで次の方法でRedisOSS構成ファイルを更新する必要があります。

「bind」ディレクティブにコメントします。これにより、RedisOSSインスタンスがインターネット上のすべてのユーザーに公開されます
「protected-mode」を「no」に設定して、認証が構成されていない場合や、「bind」ディレクティブを使用して特定のインターフェースのセットが明示的にリストされている場合でも、他のホストのクライアントがRedisに接続できるようにします。

重要： DynomiteはRedisのOSSAUTHコマンドをサポートしていないため、この最後の手順が必要です。これにより、データベースのパスワードを設定できなくなります。したがって、ファイアウォールを使用して使用中のポートに接続するユーザーを制御しない場合は、誰でも Redis OSSインスタンスに接続し、そのデータにアクセス/変更/削除できます。ポート6379をRedisEnterpriseクラスターのホストに対してのみ開きます。

本当にパスワードを使用したい場合は、使用できます。ただし、次のことを行う必要があるため、継続的な移行を実行することは不可能になります。

Dynomiteデータベースへのトラフィックを停止します
「requirepass」ディレクティブを編集して、データベースのパスワードを設定します。この時点から、データベースにアクセスするにはAUTHコマンドが必要になるため、ポート8379を使用して書き込みトラフィックをDynomiteデータベースに送信することはできなくなります。
以下に説明するように、ReplicaOfを使用して移行を実行します
RedisEnterpriseデータベースへのトラフィックをカットします

セキュリティに関するもう1つの考慮事項があり、移行を開始する準備が整いました。

オプション–TLSを有効にする

データへの不正アクセスを防ぐために、RedisEnterpriseはTLSプロトコルをサポートしています。

Redis Enterprise Softwareを使用している場合は、ReplicaOf通信用に特別に構成できます。 Redis Enterprise Cloudを使用している場合は、一般的にTLSを有効にできます。

データベース間のReplicaOfリンクを設定します

Redis Enterprise UIで、アクティブ-アクティブデータベース構成ページに移動し、[編集]をクリックします。

Active-Passive/ReplicaOfを有効にするオプションがあります。完了したら、次の形式でソースを追加できます：

redis://:@IP:port

注意：

ReplicaOfは、最大32のソースを許可します。つまり、ダイノマイトラック内の32を超えるノードにデータセットを分散している場合、このオプションを使用することはできません。
VPCピアリングを使用したことがある場合は、マシンのプライベートIPを使用する必要があります
VPCピアリングを使用したことがない場合：
- マシンのパブリックIPを使用する必要があります
- データベースにパスワードを設定する（および1回限りの移行を実行する）場合は、パスワードを次のように指定する必要があります：redis：//：password @ IP：port。

私たちの場合、VPCピアリングでは、次のようになります。

移行を開始します

それでは、次の手順を実行しましょう。

RedisEnterpriseUIで[更新]をクリックします
最初の同期が終了するのを待ちます。
Dynomiteデータベースへのトラフィックを停止します。
デルタが同期されるのを待ちます
Active-Activeデータベースを再度更新して、ReplicaOfを無効にします。
アクティブ-アクティブデータベースでトラフィックを開始します。

データを確認する

以前と同様に、redis-cliを使用してデータベースに接続し、データが移行されていることを確認します。他のクラスター/他のローカルエンドポイントに接続して、アクティブ-アクティブジオ複製も確認してください。

結論

Redisは、長年にわたって開発者から最も愛されているデータベースに選ばれています。 Dynomiteを使用している場合、それはおそらくRedisも愛しているためです。 RedisOSSとRedisEnterpriseの両方の本拠地であるRedisでは、競合解決のための最高の学術基準に対応しながら、組織がより管理しやすい方法でRedisを地理的に分散できるように支援します。

Redisを使用して献血者と患者をつなぐアプリを構築する方法

中断せずにRedisSQLクエリを実行する方法

Redis MOVE –Redisでキーをあるデータベースから別のデータベースに移動する方法
このチュートリアルでは、Redisデータストア内のあるデータベースから別のデータベースにキーを移動する方法について学習します。このために、コマンドを使用します– MOVE redis-cliで。このコマンドは、現在選択されているデータベースから指定されたキーを削除し、同じキーを宛先に挿入するために使用されますデータベース。キーがソースデータベースに存在しない場合、またはキーが宛先データベースにすでに存在する場合、操作は実行されず、0が返されます。 redis MOVEコマンドの構文は次のとおりです：- 構文：- redis host:post> MOVE <key&g
WordPress データベースをクリーンアップする方法
高速な WordPress Web サイトが必要ですか?その場合、不要なデータを削除して WordPress データベースをクリーンアップする必要があります。 WordPress データベースのクリーンアップは、Web サイトのページ読み込み時間を短縮する重要なメンテナンスタスクです。ページのキャッシュ、画像の最適化、Javascript の延期、未使用の CSS スタイルの削除など、他のパフォーマンス手法と並行して実行する必要があります。 WordPress データベースは、Web サイトのコンテンツを投稿、ページ、およびその他の投稿タイプに保存します。また、コメント、リンク、ポー