Apache CassandraからDataStax Enterpriseへのアップグレード

Apache CassandraからDataStax Enterpriseへのアップグレード手順。

重要: すべての手順を読むようにという推奨事項をご覧になったことと思います。アップグレード手順を細かく確認することで、大きな差が出てきます。やるべきことを前もって理解しておくことにより、スムーズなアップグレードが保証され、落とし穴やフラストレーションを避けることができます。

アップグレードの前にこれらの手順を読み、理解しておいてください。

アップグレード順序

アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。

  • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターへと進みます。
  • データ・センター内のシード・ノードを最初にアップグレードします。
アップグレード・パス
アップグレードは、アップグレード前のバージョンとアップグレード後のバージョンによって影響を受けます。現在のバージョンとターゲット・バージョン間のギャップが大きいほど、アップグレードは複雑になります。以前のバージョンからのアップグレードには、必要なバージョンへの中間アップグレードが必要な場合があります。
現在のバージョン 必要な中間バージョン ターゲット・バージョン
Apache Cassandra™ 3.x none DSE 5.1
Cassandra 3.0 DataStax Enterprise 5.0 DSE 5.1
Cassandra 2.1 DataStax Enterprise 4.8 DSE 5.0
Cassandra 2.0以前 DataStaxサポートにお問い合わせください。
一般的なアップグレード制限事項
  • 新しい機能を有効にしないでください
  • nodetool repairを実行しないでください。OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします。
  • アップグレード中は、ノードをブートストラップしたり、使用廃止にしたりしないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のCQLクエリーを実行しないでください。
  • アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
  • 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
任意の種類のセキュリティを使用するノードの制限事項
  • アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
ドライバー・バージョンに互換性がない場合のドライバーのアップグレードと被る可能性のある影響
ドライバーの互換性を必ず確認してください。ドライバー・バージョンによっては、クライアント・アプリケーション・コードの再コンパイルが必要になる場合があります。DataStaxドライバーのアップグレード」を参照してください。
クラスターでドライバーのバージョンが混在している場合、アップグレード中にドライバー固有の影響がある場合があります。クラスターにバージョンの混在がある場合、プロトコル・バージョンはドライバーが接続する最初のホストとネゴシエートされます。アップグレード中にドライバー・バージョンの非互換性を回避するには、以下の回避策のいずれかを使用してください。
  • 起動時のプロトコル・バージョンを強制する。たとえば、アップグレード中はJavaドライバーをv2のままにしておきます。クラスター全体がアップグレードしてから、はじめてJavaドライバーv3に切り替えてください。
  • 初期のコンタクト・ポイントのリストに、最も古いドライバー・バージョンのあるホストのみが含まれることを確認します。たとえば、初期のコンタクト・ポイントにはJavaドライバーv2のみが含まれます。
プロトコル・バージョンのネゴシエーションの詳細については、ご使用のJavaドライバー・バージョン(たとえばJavaドライバー)の「混在クラスターのあるプロトコル・バージョン」を参照してください。
アップグレード順序
アップグレードの順序は重要です。複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
  1. Analyticsデータ・センター:最初にシード・ノード、その後残りのAnalyticsノード。
  2. Cassandra(トランザクション)ノードまたはデータ・センター
  3. Searchノードまたはデータ・センター
若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。ノードは1つずつアップグレードして再起動してください。クラスター内の他のノードは、すべてのノードがアップグレードされるまで、最も古いバージョンで動作します。

dse.yaml

dse.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール

/etc/dse/dse.yaml

tarボール・インストールInstaller-No Servicesインストール

install_location/resources/dse/conf/dse.yaml

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール

/etc/cassandra/cassandra.yaml

tarボール・インストールInstaller-No Servicesインストール

install_location/conf/cassandra.yaml

手順

各ノードで次の手順に従います。

  1. Apache Cassandra™バージョンからDataStax Enterpriseにアップグレードする前に、DataStaxでは、バージョン・アップグレードの前にデータをバックアップすることをお勧めしています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。Cassandraデータのバックアップと復元」を参照してください。
  2. リリースの変更点と機能についてよく理解しておいてください。
    • DataStax Enterprise 4.74.85.0、および5.1のリリース・ノート。
    • アップグレードに関する一般的なアドバイスおよびCassandraの機能については、NEWS.txt/DSE CHANGES.txtに記載されています。以前のリリースからアップグレードする場合は、NEWS.txtで現在ご使用のバージョンに関する箇所まですべてお読みください。
    • ご使用のCassandraバージョンがDataStax Enterpriseで使用されているCassandraのバージョンに直接アップグレード可能であることを確認します。Cassandraでの変更点については、CHANGES.txt/DSE CHANGES.txtに記載されています。
  3. すべてのSSTableが最新バージョンとなるように、各ノード上のSSTableをアップグレードしてください。
    $ nodetool upgradesstables
    警告: 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。
  4. 次のようにnodetool drainを実行し、古いインストールのコミット・ログをフラッシュします。
    $ nodetool drain -h hostname
    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。
  5. ノードを停止します。(2.12.23.0
  6. 構成ファイルのバックアップを取得します。

    構成ファイルがデフォルト値で上書きされないように、構成をバックアップします。

  7. Cassandraをアンインストールします。
    APTリポジトリーまたはRPMリポジトリーのパッケージからCassandraをインストールした場合は、適切なリポジトリーからDataStax Enterpriseをセットアップおよびインストールする前に、パッケージを除去する必要があります。
    • APTリポジトリーからインストールしたパッケージの場合:
      $ sudo apt-get autoremove "dsc*" "cassandra*" "apache-cassandra*"

      Cassandraが依然として実行されている場合は、このアクションによってシャットダウンされます。

    • Yumリポジトリーからインストールしたパッケージの場合:
      $ sudo yum remove "dsc*" "cassandra*" "apache-cassandra*"

      古いCassandraの構成ファイルの名前はcassandra.yaml.rpmsaveに変更される可能性があります。

      warning: /etc/cassandra/default.conf/cassandra.yaml
      saved as /etc/cassandra/default.conf/cassandra.yaml.rpmsave
    • バイナリーtarボールを使用してCassandraがインストールされている場合:
      $ ps auwx | grep cassandra
      $ sudo  kill cassandra_pid

      その後、Cassandraインストール・ディレクトリを削除します。

  8. 以下のいずれかを使用してDataStax Enterpriseをインストールしてください。
  9. 製品を構成するには、バックアップ構成ファイルを使用して必要な変更をすべて新しい構成ファイルにマージします。
  10. ノードを起動します。
    • パッケージおよびInstaller-Servicesのインストール:「DataStax Enterpriseをサービスとして起動」(4.85.05.1)を参照してください。
    • Installer-No Servicesおよびtarボールのインストール:「DataStax Enterpriseをスタンドアローン・プロセスとして起動」(4.85.05.1)を参照してください。
  11. オプション: 最適なパフォーマンスを確保するには、アップグレードの完了後に各ノードでSSTableをアップグレードします。
    $ nodetool upgradesstables
    SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。
  12. 警告、エラー、および例外がないか、ログを確認します。
    多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。
  13. アップグレード後のデータ・センター名がキースペース・スキーマ定義で使用されたデータ・センター名と一致することを確認します。
    $ nodetool status
  14. 推奨される順序に従って、クラスター内の各ノードでアップグレードを繰り返します