DataStax クラスターに移行しようとしている Cassandra クラスター (3 つのノード、すべてのノードが AWS にデプロイされている) があります。これらのノードを自分で管理するのをやめる時が来ました。
複数のプロデューサーとコンシューマーがいて、一日中、Cassandra クラスターに対してデータの読み取り/書き込みを行っています。アプリ/サービス/プロキシを Cassandra クラスターの前に配置してから、スイッチをきれいに切り替えて、すべての読み取り/書き込みが Cassandra との間で DataStax に行われるようにするオプションはありません。そのため、一度に 1 つずつテーブルを移行するクリーンな方法はありません。また、データのすべてのプロデューサー/コンシューマーのダウンタイムをゼロ (またはほぼゼロ) にしようとしています。厳しい要件の 1 つは、移行に損失が発生しないことです。データ紛失なし！
ここでの最善の戦略は、次の 4 つのステップのプロセスであると考えています。
- どういうわけか、DataStax を Cassandra クラスターのレプリカとして構成し、DataStax へのストリーミング レプリケーションを効果的に作成します。
- DataStax が Cassandra の他のノードに完全に「追いついた」場合、プロデューサーは現在の Cassandra クラスターに書き込みを続けますが、コンシューマー/リーダーは DataStax にカットオーバーします (つまり、DataStax に接続するように再構成してから再起動します)。 ）。ダウンタイムがゼロではありませんが、単純な再起動でおそらく生きていけるでしょう。(繰り返しますが、ゼロ ダウンタイム ソリューションが非常に好まれます。 )
- プロデューサーを DataStax に切り替えます。繰り返しになりますが、ダウンタイムはほぼゼロです。これには、プロデューサーが DataStax を指すように再構成する必要があり、その後、新しい構成を取得するために再起動が必要になるためです。ゼロ ダウンタイム ソリューションが優先されます。
- 「古い」Cassandraクラスターからのレプリケーション トラフィックがゼロになると、DataStax以外のノードがDataStaxに書き込む必要がある「新しい」情報がなくなります。それらのノードを火で殺します。
このソリューションは、私が思いつくことができる最も侵襲性が低く、ダウンタイムがゼロに最も近いソリューションですが、いくつかのことを前提としています。
- おそらく、DataStax をレプリケートできる余分なノードのように扱うことは不可能です (はい/いいえ? )
- おそらく、Cassandra および/または DataStax には、このソリューションよりも優れた移行を処理できる、私が知らない魔法の機能/機能がいくつかあります。または、これをより適切に処理できるサードパーティ (理想的にはオープンソース) のツールがあるかもしれません。
- 「古い」CassandraノードからDataStaxへのレプリケーション「トラフィック」を監視する方法がわかりません。安全にシャットダウンして古いノードを強制終了する前に、これを行う方法を知る必要があります (繰り返しますが、データを失うことはありません)。
この戦略が (1) 実行可能/実行可能であり、(2) 最適であるかどうか疑問に思っていると思います。また、Cassandra/DataStax エコシステムに、これを改善するために活用できる機能/ツールがあれば (より速く、ダウンタイムなしで)。