ベンスレーター 、Instaclustrのチーフプロダクトオフィサー。
ライブのApacheCassandraデプロイメントを新しい場所に移動しますか？プロセス全体でCassandraクラスターを100％利用できるようにする方法など、いくつかの懸念があるのは当然です。ただし、実際には、接続設定の変更中もアプリケーションをオンラインのままにしておくことができれば、この移行中もアプリケーションを完全に利用できるようにすることができます。保護を強化して安心させるために、次の手法には、移行が完了するまで、元の構成に戻すための迅速なロールバック戦略も含まれています。
ダウンタイムを回避するために推奨される7ステップのCassandraクラスター移行の操作順序は次のとおりです。
1。既存の環境を準備します。
まず、アプリケーションがデータセンター対応の負荷分散ポリシーとLOCAL_*を使用していることを確認します。また、すべて 新しいクラスターにコピーされるキースペースのうち、レプリケーション戦略としてNetworkTopologyStrategyを使用するように設定されています。また、後で変更すると複雑になる可能性があるため、作成時にすべてのキースペースでこのレプリケーション戦略を使用することをお勧めします。
2。新しいクラスターを作成します。
次に、移行先の新しいクラスターを作成します。ここで注意すべき点がいくつかあります。新しいクラスターと元のクラスターが同じCassandraバージョンとクラスター名を使用していることを確認してください。また、使用する新しいデータセンター名は、既存のデータセンターの名前とは異なる必要があります。
3。一緒にクラスターに参加します。
これを行うには、最初に必要なファイアウォールルールの変更を行って、クラスターを参加できるようにします。ソースクラスターへの変更も必要になる場合があることに注意してください。次に、新しいクラスターのシードノードを変更して開始します。これが完了すると、新しいクラスターは元のクラスターの2番目のデータセンターになります。
4。レプリケーション設定を変更します。
次に、既存のクラスターで、コピーされるキースペースのレプリケーション設定を更新して、データが新しいデータセンターを宛先としてレプリケートされるようにします。
5。データを新しいクラスターにコピーします。
クラスタが結合されると、Cassandraは新しいクラスタへの書き込みの複製を開始します。ただし、nodetool再構築機能を使用して既存のデータをコピーする必要があります。既存のクラスターに圧倒的なストリーミング負荷がかからないように、この機能を新しいクラスターで一度に1つまたは2つのノードで実行することをお勧めします。
6。アプリケーションの接続ポイントを切り替えます。
再構築機能のすべての使用が完了すると、各クラスターには、移行されるデータの完全なコピーが含まれ、Cassandraは自動的に同期を維持します。次に、アプリケーションの初期接続ポイントを新しいクラスターのノードに変更します。これが完了すると、すべての読み取りと書き込みが新しいクラスターによって処理され、その後、元のクラスターに複製されます。最後に、クラスター全体で修復機能を実行して、すべてのデータが元のデータから正常に複製されていることを確認するのが賢明です。
7。元のクラスターをシャットダウンします。
元のクラスターを削除して、移行後のクリーンアップを少し行ってプロセスを完了します。まず、ファイアウォールルールを変更して、元のクラスターを新しいクラスターから切断します。次に、新しいクラスターのレプリケーション設定を更新して、元のクラスターへのデータのレプリケーションを停止します。最後に、元のクラスターをシャットダウンします。
これで、Apache Cassandraのデプロイメントが完全に移行され、ダウンタイムがゼロで、リスクが低く、エンドユーザーの観点から完全にシームレスで透過的です。
作者について
ベンスレーター は、クラウド内のエンタープライズグレードのホスト型で完全に管理されたApacheCassandraオープンソースデータインフラストラクチャのプロバイダーであるInstaclustrの最高製品責任者です。