DataStax Enterprise 2.2から3.2へのアップグレード
DataStax Enterprise 2.2.xから3.2.xにアップグレードするには、以下の手順に従います。
DataStax Enterprise 2.2.xから3.2.xにアップグレードするには、以下の情報を確認してください。
セキュリティ上の推奨事項
セキュリティを設定する前にクラスター全体をアップグレードしてから、ローリング再起動を実行します。
Hadoop
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)。
- system.logファイルを開き、Solrエラーに関するメッセージを探します。
エラー・メッセージでは、必要な変更について簡単に説明しています。
- solrconfig.xmlファイルでこれらのエラーを修正し、修正済みファイルを送信します。
solrconfig.xmlのエラーが解決されるまで、既存のコアは読み込めません。
- アップグレード済みの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ファイルでオプションを設定します。
dse_auth
キースペースのレプリケーション係数を1より大きく構成します。- Kerberos
- オブジェクト・パーミッション管理(内部権限管理)
- 内部認証
dse_auth
のレプリケーション係数を調整します。cassandra.yamlファイルを更新してノードを再起動した後、nodetool repair
を実行して、パーティショナーにより返される、キースペースの最初の範囲をリペアします。nodetool repair dse_auth -pr
完了までにかかる時間は、ほんの数秒です。
- authenticator
- authorizer
- auth_replication_strategy
- auth_replication_options
- その他の差分
- authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator
- authorizer: org.apache.cassandra.auth.CassandraAuthorizer
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の値に変更し、後述するローリング再起動を実行します。
- 正式なApacheバージョンの
PasswordAuthenticator
およびCassandraAuthorizer
に切り替わるように、cassandra.yamlを編集します。authenticator: org.apache.cassandra.auth.PasswordAuthenticator authorizer: org.apache.cassandra.auth.CassandraAuthorizer
- cassandra.yamlファイルから、以下のオプションを除去またはコメント・アウトします。
- auth_replication_strategy
- auth_replication_options
- replication_factor
注:auth_replication_strategy
およびreplication_factor
のどちらも無効にしていない場合は、エラーが表示されます。エラーの修正方法の詳細については、「DataStax Enterprise 3.2.5リリース・ノートの問題点」を参照してください。 - 任意で、
system_auth
キースペースのレプリケーション係数を調整します。通常、このキースペースのデータは少量であり、クラスター間でレプリケートされるままにしておいても、比較的負担が少なくて済みます。
仮想ノード(vnode)
vnodeは、Cassandraワークロードを実行しているデータ・センターのみで使用することを推奨します。HadoopワークロードまたはSolrワークロードを実行するデータ・センターでvnodeを無効にするには、cassandra.yamlでnum_tokensを1に設定します。