DataStax Enterprise 3.0から3.2へのアップグレード

DataStax Enterprise 3.0.xからDataStax Enterprise 3.2.xにアップグレードします。

DataStax Enterprise 3.0.xからDataStax Enterprise 3.2.xにアップグレードするには、以下の情報を確認し、手順に従います。

dse.yaml

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

パッケージ・インストール
                  Installer-Servicesのインストール（DSE 4.5～5.1）

 /etc/dse/dse.yaml

tarボール・インストール
                   Installer-No Servicesのインストール（DSE 4.5～5.1）

 install_location/resources/dse/conf/dse.yaml

cassandra.yaml

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

パッケージ・インストール
                  Installer-Servicesのインストール（DSE 4.5～5.1）

 /etc/cassandra/cassandra.yaml

tarボール・インストール
                   Installer-No Servicesのインストール（DSE 4.5～5.1）

 install_location/conf/cassandra.yaml

Analyticsノード

クラスターのアップグレード時に、Hadoopインターフェイスを通じて作成されたカラム・ファミリーの一部が、データを含んでいるように見えないことがあります。アップグレード・プロセスが完了すると、データは再度表示されます。

パーティショナー

cassandra.yamlファイルを編集して、前のパーティショナーと一致するようにパーティショナーの設定を変更します。デフォルトのRandomPartitioner（org.apache.cassandra.dht.RandomPartitioner）は、Apache Cassandra™ 1.2よりも前のデフォルトのパーティショナーでした。

CQL 3

すべてのノードがアップグレードされ、スキーマの不一致が解決されるまで、CQL 3クエリーを発行しないでください。

セキュリティ上の推奨事項

クライアントとノード間のSSLを有効にするためのclient_encryption_optionsは、3.1.2以降では dse.yaml から削除されました。クライアントとノード間のSSLを有効にするには、 cassandra.yamlファイルでオプションを設定します。

3.0.xから3.2.xにアップグレードする前に、DataStax Enterpriseのこれらのセキュリティ機能を使用している場合は、cassandra.yamlファイルのレプリケーション・ストラテジおよびオプションを調整し、dse_authキースペースのレプリケーション係数を1より大きく構成します。
  • Kerberos
  • オブジェクト・パーミッション管理（内部権限管理）
  • 内部認証
クラスターの各ノードのdse_authのレプリケーション係数を調整します。cassandra.yamlファイルを更新してノードを再起動した後、nodetool repairを実行して、パーティショナーにより返される、キースペースの最初の範囲をリペアします。
nodetool repair dse_auth -pr

完了までにかかる時間は、ほんの数秒です。

Apache Cassandra™の新しいバージョンによりセキュリティ・オプションが更新されます。最初に、以下の設定を新しい構成ファイルにマージします。
  • authenticator
  • authorizer
  • auth_replication_strategy
  • auth_replication_options
  • その他の差分
クラスターのアップグレード時は、後方互換性を維持するために、古い設定を使用します。たとえば、現時点で、新しいファイルに古いCassandra 1.1の認証用のオーセンティケーター（authenticator）オプションおよび権限設定用のオーソライザー（authorizer）オプションが含まれている場合は、以下のようになります。
  • authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator
  • authorizer: org.apache.cassandra.auth.CassandraAuthorizer
セキュアなクラスターをアップグレードする場合、セキュリティの移行が発生するため、各ノードの最初の起動で大きな遅れ（最大1分）が発生することがあります。この遅れは、移行が開始する前にリングが完全に接続されるようにするために発生します。セキュアなクラスターをアップグレードする間、セキュリティ関連のエラー・メッセージが表示されることがあります（後述）。ノードによる移行が完了すると、ログに以下のメッセージが表示されます。
INFO [NonPeriodicTasks:1 ] 2013-06-22 15:01:08,173
Auth.java  (line 208 ) Migration of legacy auth data is complete.
You should now switch to org.apache.cassandra.auth implementations in cassandra.yaml.

すべてのノードがアップグレードされた後、これらのオプションを新しいCassandra 1.2の値に変更し、後述するローリング再起動を実行します。

注: Kerberos認証を使用している場合、移行対象の認証情報データはありませんが、ユーザー・レコードの更新が必要です。関連する差分を、古いファイルから新しいファイルにマージします。
  1. 正式なApacheバージョンのPasswordAuthenticatorおよびCassandraAuthorizerに切り替わるように、cassandra.yamlを編集します。
    authenticator: org.apache.cassandra.auth.PasswordAuthenticator
authorizer: org.apache.cassandra.auth.CassandraAuthorizer
  2. cassandra.yamlファイルから、以下のオプションを除去またはコメント・アウトします。
    • auth_replication_strategy
    • auth_replication_options
    • replication_factor
    注:

    auth_replication_strategyおよびreplication_factorのどちらも無効にしていない場合は、エラーが表示されます。エラーの修正方法の詳細については、「DataStax Enterprise 3.2.5リリース・ノートの問題点」を参照してください。

  3. 任意で、system_authキースペースのレプリケーション係数を調整します。通常、このキースペースのデータは少量であり、クラスター間でレプリケートされるままにしておいても、比較的負担が少なくて済みます。

仮想ノード（vnode）

vnodeは、Cassandraワークロードを実行しているデータ・センターのみで使用することを推奨します。HadoopワークロードまたはSolrワークロードを実行するデータ・センターでvnodeを無効にするには、cassandra.yamlでnum_tokensを1に設定します。

Solr

アップグレード後にSolrノードの構成を変更する場合は、「Solr型マッピング・バージョンの構成」で説明しているように、型マッピングを正しく設定する必要があります。

ノードの使用再開

過去72時間以内にノードを使用廃止した場合：
  • さらに72時間が経過するまで、ノードを使用再開しないでください。
  • 72時間後にノードを使用再開する必要がある場合は、nodetool gossipinfoを実行します。STATUS行をチェックして、使用廃止したノードのトークンが存在しないことを確認します。存在しない場合は、ノードが削除されているため、ノードの使用再開を安全に行うことができます。
  • クラスターのノードの使用再開を必要とする場合は、ノードを強制終了する方法について、サポートまでお問い合わせください。