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

DataStax Enterprise 2.2.xから3.2.xにアップグレードするには、以下の手順に従います。

DataStax Enterprise 2.2.xから3.2.xにアップグレードするには、以下の情報を確認してください。

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

セキュリティを設定する前にクラスター全体をアップグレードしてから、ローリング再起動を実行します。

Hadoop

CassandraFSのHadoop mapred stagingディレクトリーの所有権が変更されています。アップグレード後、/tmp/hadoop-dseuser/mapred/stagingの所有者をDataStax Enterpriseユーザーに設定する必要があります。たとえば、rootとしてDataStax Enterprise 3.1を実行する場合は、Linuxで以下のコマンドを使用します。
dse hadoop fs -chown root /tmp/hadoop-root/mapred/staging

Solr

DataStax Enterprise 2.1.x以前からアップグレードした後、すべてのノードがアップグレードされ、スキーマの不一致が解決されるまで、Solrクエリーを発行しないでください。

以前のバージョンのDataStax Enterpriseに基づくSolr構成ファイルは、このリリースに含まれる新バージョンのSolrにより無効にされます。以下の手順に従って、最初にアップグレードしたSolrノードでSolr構成ファイルを更新します（以下の手順1、手順2）。その後、他のノードをアップグレードします（手順3）。

  1. system.logファイルを開き、Solrエラーに関するメッセージを探します。

    エラー・メッセージでは、必要な変更について簡単に説明しています。

  2. solrconfig.xmlファイルでこれらのエラーを修正し、修正済みファイルを送信します。

    solrconfig.xmlのエラーが解決されるまで、既存のコアは読み込めません。

  3. アップグレード済みのSolrの各ノードでインデックスを復旧するために以下のコマンドを発行します。アップグレードした最初のノードでは、Solr構成ファイルをアップロードした後に、このプロセスを実行します。以下のコマンドでは、Solrコアの名前を環境にあったものに置き換えて実行してください。
    curl -v "http://localhost:8983/solr/admin/cores?action=CREATE&solr core.solr&recovery=true"

以下の例は、DataStaxが提供しているSolrベースのデモを対象に上記の手順を実行する方法を示します。テスト・クラスターでこの手順をテスト実行する場合は、旧バージョンのDataStax Enterpriseを実行しているテスト・クラスターで、solr、wiki、およびloggingの各デモをあらかじめ実行しておきます。

まず、Solrアプリケーションを含むディレクトリーに移動します。たとえば、demosディレクトリーに移動します。

  • バイナリー・インストール

    cd install_location/demos

  • パッケージ・インストール

    cd /usr/share/dse-demos

以下のコマンドを実行し、変更したカスタムsolrconfig.xmlをDSE SearchにHTTP-POST送信します。たとえば、demosディレクトリーまたはdse-demosディレクトリーから、以下のコマンドを実行します。

  • solr_stressディレクトリーの場合：

    curl -v --data-binary @solrconfig.xml -H 'Content-type:text/xml; charset=utf-8'
http://localhost:8983/solr/resource/demo.solr/solrconfig.xml

  • wikipediaディレクトリーの場合：

    curl -v --data-binary @solrconfig.xml -H 'Content-type:text/xml; charset=utf-8'
http://localhost:8983/solr/resource/wiki.solr/solrconfig.xml

  • log_searchディレクトリーの場合：

    curl -v --data-binary @solrconfig.xml -H 'Content-type:text/xml; charset=utf-8'
http://localhost:8983/solr/resource/Logging.log_entries/solrconfig.xml

    各curlコマンドを実行した後、SUCCESSメッセージが表示されます。

ここまでの手順が必要となるのは、最初のノードのアップグレード時の1回のみです。

各ノードをアップグレードした後、復旧オプションをtrue、分散オプションをfalseに設定してCREATEコマンドを実行します。

curl -v "http://localhost:8983/solr/admin/cores?action=CREATE&name=demo.solr&recovery=true"
$ curl -v  "http://localhost:8983/solr/admin/cores?action=CREATE&name=wiki.solr&recovery=true"
$ curl -v  "http://localhost:8983/solr/admin/cores?action=CREATE&name=Logging.log_entries&recovery=true"

パーティショナー

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型マッピング・バージョンの構成」で説明しているように、型マッピングを正しく設定する必要があります。