DataStax Enterprise
DataStaxアップグレード・ガイド ドキュメント 2015年04月23日 © 2015 DataStax. All rights reserved. | 目次 | 目次 アップグレード・ガイドについて.............................................................................................. 4 DataStax Enterpriseのアップグレード................................................................................ 5 一般的なアップグレード手順...................................................................................................................5 アップグレード手順の詳細........................................................................................................... 5 LinuxディストリビューションでDSE tarボールをインストールするためのアップグレード手順。......................7 Debianベースのアップグレード手順........................................................................................................8 RHELベースのアップグレード手順..........................................................................................................8 GUIインストーラーを使用してLinux上インストールをアップグレード...........................................................9 バージョン固有のアップグレード手順.................................................................................................... 10 DataStax Enterprise 3.2へのアップグレード............................................................................. 10 DataStax Enterprise 4.0へのアップグレード............................................................................. 19 DataStax Enterprise 4.5へのアップグレード............................................................................. 21 DataStax AMIのアップグレード............................................................................................................21 アップグレードのロールバック................................................................................................................22 パッケージ・インストールから以前のバージョンに戻す................................................................. 22 tarボール・インストールから以前のバージョンに戻す...................................................................23 DataStax CommunityからDataStax Enterpriseへのアップグレード.................................24 Cassandraのアップグレード.............................................................................................. 26 バージョンに関する制約事項................................................................................................................26 ベスト・プラクティス.............................................................................................................................. 26 アップグレード手順の詳細.................................................................................................................... 27 DebianまたはUbuntu................................................................................................................28 RHELまたはCentOS................................................................................................................ 28 tarボール..................................................................................................................................29 アップグレードへの影響のある変更....................................................................................................... 29 OpsCenterのアップグレード.............................................................................................. 31 パッケージ・インストールのアップグレード.............................................................................................. 31 tarボール・インストールのアップグレード................................................................................................32 エージェントのアップグレード................................................................................................................33 Datastaxのドキュメントを使用するためのヒント................................................................... 34 アップグレード・ガイドについて アップグレード・ガイドについて このドキュメントでは、DataStax Enterprise、Cassandra、およびOpsCenterのアップグレード手順を詳しく説明しま す。 各アップグレードの手順 4 • DataStax Enterpriseのアップグレード • Cassandraのアップグレード • OpsCenterのアップグレード DataStax Enterpriseのアップグレード DataStax Enterpriseのアップグレード このセクションでは、最新バージョンのDSEにアップグレードする方法を説明します。 一般的なアップグレード手順 DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化（ゼロ・ダウンタイムが理想）を目指してい ます。例外を除き、クラスターは、クラスター内のすべてのノードがアップグレードされるまで、以前のバージョンと同じ ように使用できます。 ノードをアップグレードする順番は重要です。アップグレードを計画するときのガイドラインは以下です。 • 複数のデータ・センターで構成されているクラスターでは、1つのデータ・センターのすべてのノードをアップグレー ドしてから、次のデータ・センターに取り組みます。 • 最初にAnalyticsノードまたはデータ・センター、次にCassandraノードまたはデータ・センター、最後にSearchノー ドまたはデータ・センターをアップグレードします。 • Analyticsノードがある場合は、最初にデータ・センターのジョブトラッカーを含むノードをアップグレードします。 • シード・ノードはデータ・センターの中で最初にアップグレードします。 ダウンタイムなしでのアップグレードを実行するには、ローリング再起動としてのアップグレードの実行を推奨します。 ローリング・アップグレードの手順は以下のとおりです。 1. アップグレードするノードのスナップショットを取得して、データのバックアップを作成します。 2. ノードを停止します。 3. 新しいバージョンの製品をインストールします。 4. 新しいバージョンの製品を構成します。 5. ノードを起動します。 6. 警告、エラー、および例外がないか、ログをチェックします。 7. クラスター内のノードごとに以上の手順を繰り返します。 クラスターの一部が部分的にアップグレードされている状態のときは、一般的な制限事項を守ってください。 アップグレード手順の詳細 About this task このセクションでは、クラスターのノードをアップグレードする手順を説明します。 Before you begin ノードを停止する前に、nodetool drainを実行し、現在インストールされている環境のコミット・ログをフラッシュしま す。 $ nodetool drain –h ホスト名 DSE Search/Solrノードをアップグレードする場合は、データのインデックスを再作成しなくて済むようにこの手順は 必須です。この手順は、ノードの立ち上げに要する時間を短縮できるため、その他のノードをアップグレードする場合 にも推奨されます。 5 DataStax Enterpriseのアップグレード CHANGES.txtおよびNEWS.txtに記述されている内容を読み、新しいCassandraバージョンの変更点や機能につ いてよく理解してください。CHANGES.txtはすべての変更点についての情報、NEWS.txtはアップグレードのアドバ イス、新たな機能についての情報を入手できます。 Procedure 1. ノードを停止します。 2. 構成ファイルのバックアップを取得します。 製品のインストール方法によっては、インストール時にこれらのファイルがデフォルト値で上書きされてしまう可能 性があります。構成のバックアップを取得したら、現在のインストールの種類に応じた適切なインストール手順に 従います。 3. 新しいバージョンの製品をインストールします。 • バイナリーtarボール・インストール • Debianベースのインストール • RHELベースのインストール 4. 新しいバージョンの製品を構成します。 構成ファイルから取得したバックアップを使用して、以前に利用していた変更を、新バージョンの新しい構成ファ イルにマージします。構成オプションはたびたび変更されるため、構成に関する追加の手順および変更について、 「バージョン固有のアップグレード手順」を念入りにチェックしてください。 5. ノードを起動します。 インストール・タイプに応じた手順に従います。 • パッケージ・インストール（DebianおよびRHEL）の場合は、DataStax Enterpriseをサービスとして起動しま す。 • バイナリーtarボール・インストールの場合は、DataStax Enterpriseをスタンドアロン・プロセスとして起動しま す。 6. メジャー・バージョンからのアップグレード（たとえばDataStax Enterprise 3.2から4.0へのアップグレード）または メジャー・ポイント・リリースのアップグレード（たとえばCassandra 1.1.xから1.2.xへのアップグレード）の場合は、 各ノードでsstablesをアップグレードします。 $ nodetool upgradesstables 7. 警告、エラー、および例外がないか、ログをチェックします。 多くの場合、アップグレードしたノードの起動時に、警告、エラー、および例外がログに表示されます。これらの情 報の一部は、固有のアップグレード関連の手順を実行するときに役立ちます。これらのうち予想されるものはど れなのか、また、これらの警告およびエラーを参考にアップグレードを完了する手順については、「バージョン固有 のアップグレード手順」を確認してください。予想されない警告、エラー、または例外が表示された場合は、サポー トまでお問い合わせください。 8. クラスターの各ノードについて手順を繰り返します。 アップグレードするノードの順序は重要です。ノードは以下の順序でアップグレードしてください。 1. Analytics：ジョブトラッカー、残りのシード、残りのタスク・トラッカー。 2. Cassandra：シード・ノードの後に残りのノード。 3. Solr：シード・ノードの後に残りのノード。 クラスターの一部が部分的にアップグレードされている状態での一般的な制限事項： 6 • nodetool repairを実行しないでください。 • 新しい機能を使用しないでください。 DataStax Enterpriseのアップグレード • ローリング再起動中に、DDL、TRUNCATEのような種類のクエリーを実行しないでください。 • Hadoop固有の制限事項： • • • Mapreduceジョブを実行しないでください。 Solr固有の制限事項： • スキーマを更新しないでください。 • インデックスを再作成するためのアップグレード手順の中の指示に従っている場合を除き、Solrのインデッ クスを再作成しないでください。 • ローリング再起動中に、DDL、TRUNCATEの種類のクエリー、およびSolrクエリーを発行しないでください。 セキュリティ上の制限事項： • アップグレードが完了するまで、セキュリティ認証情報またはパーミッションを変更しないでください。 • Kerberos認証をセットアップしないでください。最初にクラスターをアップグレードしてからKerberosをセッ トアップしてください。 LinuxディストリビューションでDSE tarボールをインストールするためのアップグレード 手順。 About this task この手順では、最新バージョンのDatastax Enterpriseバイナリーtarボールをインストールし、既存のインストールを 置き換える方法を示します。 インストールを実行する前に、今後参照するために構成ファイルのバックアップを必ず取得してください。 ノードのアップグレードとデータの移行 Procedure 1. ユーザー名およびパスワードを使用し、DataStax Enterprise tarボールをダウンロードします。 $ curl -OL http://username:[email protected]/enterprise/ dse.tar.gz usernameおよびpasswordは、DataStax登録確認の電子メールに記載されています。電子メールを受け取って いない場合は、DataStax Webサイトで登録してください。 2. 新しいインストール用のディレクトリーを作成し、そのディレクトリーにtarボールを移動します。 3. DataStax Enterprise tarボールをアンパックします。 $ tar xzvf dse-4.5 tarball name 4. RHEL 5またはCentOS 5プラットフォームの場合のみ、snappy-java-1.0.5.jarのすべてのインスタンス を、1.0.4.1 JARで置き換えます（こちらから入手できます）。 $ rm resources/cassandra/lib/snappy-java-1.0.5.jar resources/hadoop/lib/ snappy-java-1.0.5.jar resources/hive/lib/snappy-java-1.0.5.jar resources/ pig/lib/snappy-java-1.0.5.jar $ curl -OL http://username:[email protected]/enterprise/ snappy-java-1.0.4.1.jar $ cp snappy-java-1.0.4.1.jar resources/cassandra/lib/ $ cp snappy-java-1.0.4.1.jar resources/hadoop/lib/ $ cp snappy-java-1.0.4.1.jar resources/hive/lib/ $ cp snappy-java-1.0.4.1.jar resources/pig/lib/ 7 DataStax Enterpriseのアップグレード 5. 古いインストールのデータの場所をカスタマイズした場合は、古いデータ・ディレクトリーへのシンボリック・リンク を作成します。 $ cd new install location $ ln -s old data directory new install location/new data directory Debianベースのアップグレード手順 About this task この手順では、Advanced Package Tool、apt-getを使用して新バージョンのDatastax Enterpriseをインストール する方法を示します。 apt-getは、以前に行った変更を上書きするため、このプロセスを開始する前に構成ファイルのバックアップを必ず取 得してください。 Procedure 1. DataStax Communityバージョンを使用していた場合は、ユーザー名およびパスワードを使用し、DataStaxリポ ジトリを/etc/apt/sources.listに追加します。 $ deb http://username:[email protected]/enterprise stable main usernameおよびpasswordは、DataStax登録確認の電子メールに記載されています。電子メールを受け取って いない場合は、DataStax Webサイトで登録してください。 2. ノードをアップグレードします。 $ sudo apt-get update $ sudo apt-get install dse-full 3. 使用するディスク領域について通知するプロンプトが表示された場合は、Yを入力して続行します。 RHELベースのアップグレード手順 About this task この手順では、Yum Package Managerを使用して新バージョンのDatastax Enterpriseをインストールする方法を 示します。 このプロセスを開始する前に構成ファイルのバックアップを必ず取得してください。また、Yumが.rpmsave拡張子 ファイルのバックアップファイルを作成している可能性があります。例えばcassandra.yaml.rpmsaveといった ファイルです。 Procedure 1. /etc/yum.repos.dにあるDataStax EnterpriseのYumリポジトリ・ファイルを開いて編集します。 $ sudo vi /etc/yum.repos.d/datastax.repo 2. ユーザー名およびパスワードを使用し、ファイルの内容を以下の行で置き換えます。 [datastax ] name = DataStax Repo for Apache Cassandra baseurl = http://username:[email protected]/enterprise 8 DataStax Enterpriseのアップグレード enabled = 1 gpgcheck = 0 usernameおよびpasswordは、DataStax登録確認の電子メールに記載されています。電子メールを受け取って いない場合は、DataStax Webサイトで登録してください。 3. ノードをアップグレードします。 $ sudo yum uninstall dse-full $ sudo yum install dse-full 4. ダウンロード・サイズについて確認を求めるプロンプトが表示された場合は、Yを入力して続行します。 GUIインストーラーを使用してLinux上インストールをアップグレード About this task この手順では、GUIインストーラーを使用して最新バージョンのDatastax Enterpriseにアップグレードする方法を示 します。 Before you begin 最新バージョンのDataStax Enterpriseにアップグレードするには、以下の要件を満たす必要があります。 • DataStax Enterprise 4.0.x以降のインストールがあること。 • 現在のインストールが以下のいずれかを使用してインストールされていること。 • yum（RHELまたはCentOS）、またはapt（DebianまたはUbuntu）パッケージ・マネージャー。 • GUIインストーラー（サービス・インストール）。 Procedure 1. お使いのコンピューター用のインストーラーを、DataStaxダウンロード・ページからダウンロードします。 2. インストール・ファイルをダウンロードしたディレクトリーで、ファイルを実行可能に変更し、sudoコマンドを使用して 実行します。 $ chmod +x DataStaxEnterprise-4.5.x-linux-x64-installer.run ## Changes permission to executable $ sudo ./DataStaxEnterprise-4.5.x-linux-x64-installer.run 3. セットアップ・ウィザードの指示に従います。ウィザードの設定方法の詳細な説明については、『Getting Start Guide』を参照してください。 4. サービスを開始します。 $ sudo service dse start ## Starts the DataStax Enterprise server $ sudo service datastax-agent start ## Starts the DataStax Agent $ sudo service opscenterd start ## Starts the OpsCenter 5. nodetoolコマンドを使用して、DataStax Enterpriseが稼働していることを確認します。 $ nodetool status 9 DataStax Enterpriseのアップグレード バージョン固有のアップグレード手順 任意のバージョンのDataStax Communityからアップグレードするには、「DataStax Communityバージョンからの アップグレード」の手順に従います。 Briskリリースからアップグレードする場合は、サポートまでご連絡ください。 DataStax Enterprise 3.2へのアップグレード DSE 3.2.xにアップグレードするには、以下の手順に従います。 以下のもの以外のバージョンから直接アップグレードすることはできません。 • DataStax Enterprise 2.2.2以降 • Cassandra 1.1.9〜1.2.15 • DataStax Community 1.1（Cassandra 1.1.9） また、多くのバージョンのアップグレードには、固有の制限があるか、特別な手順が必要な場合があります。以下の表 で現在のバージョンを探し、リンク先のページの手順に従います。 現在のバージョン アップグレード手順 2.2.2 バージョン2.2.xからのアップグレード 3.0 バージョン3.0.xからのアップグレード 3.1 バージョン3.1.xからのアップグレード バージョン2.2.xからのアップグレード About this task DSE 2.2.xからアップグレードするには、以下の手順に従います。 セキュリティ上の推奨事項 セキュリティ機能を使用する場合、セキュリティ機能を設定する前にクラスター全体をアップグレードしてから、設定後 にローリング再起動を再実行する必要があります。 Hadoop CassandraFSのHadoop mapred stagingディレクトリーのオーナーが変更されています。アップグレード後、/ tmp/hadoop-dseuser/mapred/staging のオーナーをDSEユーザーに設定する必要があります。たとえ ば、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）。 10 DataStax Enterpriseのアップグレード 1. system.logを開き、Solrエラーに関するメッセージを探します。 エラー・メッセージでは、必要な変更について簡単に説明しています。 2. solrconfig.xmlファイルでこれらのエラーを修正し、修正済みファイルを送信します。 solrconfig.xmlのエラーが解決されるまで、既存のコアは読み込めません。 3. アップグレード済みのSolrの各ノードでインデックスを復旧するために以下のコマンドを発行します。アップグレー ドした最初のノードでは、Solr構成ファイルをアップロードした後に、このプロセスを実行します。以下のコマンドで は、Solrコアの名前を環境にあったものに置き換えて実行してください。 $ curl -v "http://localhost:8983/solr/admin/cores?action=CREATE&Solrコ ア.solr&recovery=true" 以下の例は、DataStaxが提供しているSolrベースのデモを対象に上記の手順を実行する方法を示します。テ スト・クラスターでこの手順をテスト実行する場合は、旧バージョンのDSEを実行しているテスト・クラスター で、solr、wiki、およびloggingの各デモをあらかじめ実行しておきます。 まず始めに、Solrアプリケーションを含むディレクトリーに移動します。たとえば、demosディレクトリーに移動します。 • バイナリー・インストール • $ cd インストール場所/demos パッケージ・インストール $ cd /usr/share/dse-demos 以下のコマンドを実行し、変更したカスタムsolrconfig.xmlをDSE-SearchにHTTP送信します。たとえ ば、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" 11 DataStax Enterpriseのアップグレード パーティショナー 以前のファイルのパーティショナー設定を新しいファイルにマージします。すでに使用していた場合を除き、新しい ファイルのCassandra 1.2のデフォルトのパーティショナー・オプション、Murmur3Partitionerを使用しないで以前の ファイルのパーティショナーに書き換えてご使用ください。 CQL 3 すべてのノードがアップグレードされ、スキーマの不一致が解決されるまで、CQL 3クエリーを発行しないでください。 セキュリティ上の推奨事項 クライアントとノード間のSSLを有効にするclient_encryption_optionsは、3.1.2より、dse.yamlから除外 されました。クライアントとノード間のSSLを有効にするには、cassandra.yamlファイルのオプションとして設定し ます。 アップグレードする前に、DataStax Enterpriseのこれらのセキュリティ機能を使用している場合 は、cassandra.yamlファイルのレプリケーション・ストラテジおよびオプションを調整し、dse_authキースペース のレプリケーション係数を1より大きく構成します。 • • Kerberos • 内部認証 オブジェクト・パーミッション管理（内部権限） クラスターの各ノードのdse_authのレプリケーション係数を調整します。cassandra.yamlファイルを更新して ノードを再起動した後、nodetool repairを実行して、パーティショナーにより返される、キースペースの最初の範 囲をリペアします。 nodetool repair dse_auth -pr 完了までにかかる時間は、ほんの数秒です。 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. 12 DataStax Enterpriseのアップグレード すべてのノードがアップグレードされた後、これらのオプションを新しいCassandra 1.2の値に変更し、後述するロー リング再起動を実行します。 Note: 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 Note: auth_replication_strategyおよびreplication_factorのどちらも無効にしていない場合 は、エラーが表示されます。 エラーの修正方法の詳細については、「DataStax Enterprise 3.2.5リリー ス・ノートの問題点」を参照してください。 3. 任意で、system_authキースペースのレプリケーション係数を調整します。通常、このキースペースのデータは 少量であり、クラスター間でレプリケートされるままにしておいても、比較的負担が少なくて済みます。 SSTableのアップグレード 各ノードを再起動した後、SSTableのアップグレードが必要な場合があります。以下のような場合は、SSTableのアッ プグレードを実施します。 • カウンター・カラムを使用している場合 • Cassandra 1.0.x以前からアップグレードする場合 • Cassandra 1.0.x以前を使用しているDataStax Enterpriseバージョンからアップグレードする場合 以下の操作の前にはSSTableをアップグレードします。 • ムーブ • リペア • ブートストラップ これらの操作はクラスター内のSSTableをコピーするものであり、またディスク上のフォーマットはメジャー・バージョ ンで変更される可能性があるため、DataStaxでは、今後のSSTableの非互換性の可能性を回避するため、現時点 でSSTableをアップグレードすることを推奨します。 • tarボール：インストール場所/bin/nodetool -h upgradesstables • パッケージまたはAMI：nodetool -h upgradesstables vnode DataStaxでは、vnode（仮想ノード）は、純粋なCassandraワークロードを処理するデータ・センター でのみ使用することを推奨します。AnalyticsまたはSolrワークロードを処理するデータ・センターの場 合、cassandra.yamlのnum_tokensを1に設定することにより、vnodeを無効にする必要があります。 Solr アップグレード後にSolrノードの構成を変更する場合は、「Solr型マッピング・バージョンの構成」で説明しているよう に、型マッピングを正しく設定してください。 13 DataStax Enterpriseのアップグレード 予想されるエラー・メッセージ DataStax Enterprise 3.0.xからアップグレードする場合、ローリング・アップグレード時に以下のような例外がログに 含まれていることがあります。これらのエラー・メッセージは無視してください。 ERROR 15:36:54,908 Exception in thread Thread[GossipStage:1,5,main ] java.lang.NumberFormatException:For input string:"127605887595351923798765477786913079296" . . . Cassandra 1.2ノードをアップグレードする場合、ノードが新しいsystem_authキースペースにミューテーションをプッ シュしようとしていることに関連する以下のエラー・メッセージを無視できます。 ERROR [WRITE-/192.168.123.11] 2013-06-22 14:13:42,336 OutboundTcpConnection.java (line 222) error writing to /192.168.123.11 java.lang.RuntimeException:Can't serialize ColumnFamily ID 2d324e48-3275-3517-8dd5-9a2c5b0856c5 to be used by version 5, because int <-> uuid mapping could not be established (CF was created in mixed version cluster). at org.apache.cassandra.db.ColumnFamilySerializer.cfIdSerializedSize(ColumnFamilySerializer Solrノードをアップグレードする場合、以下のエラーを無視できます。 ERROR 00:57:17,785 Cannot activate core:ks.cf_10000_keys_50_cols ERROR 00:57:17,786 <indexDefaults> and <mainIndex> configuration sections are discontinued. Use <indexConfig> instead. ERROR 01:29:55,145 checksum mismatch in segments file (resource: ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/ solr.data/ks. cf_10000_keys_50_cols/index/segments_6" ))) ERROR 01:29:55,145 Solr index ks.cf_10000_keys_50_cols seems to be corrupted: please CREATE the core again with recovery = true to start reindexing data. ERROR 01:29:55,145 Cannot activate core:ks.cf_10000_keys_50_cols ERROR 01:29:55,146 checksum mismatch in segments file (resource:ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/solr.data/ks. cf_10000_keys_50_cols/index/segments_6" ))) org.apache.lucene.index.CorruptIndexException:checksum mismatch in segments file (resource:ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/solr.data/ks.cf_10000_keys_50_cols/index/ segments_6" ))) ノードの使用再開 過去72時間以内にノードを使用廃止した場合： • 72時間が経過するまで、ノードを使用再開しないでください。 • 72時間後にノードを使用再開する必要がある場合は、nodetool gossipinfoを実行します。STATUS行を チェックして、使用廃止したノードのトークンが存在しないことを確認します。存在しない場合は、ノードが削除さ れているため、ノードの使用再開を安全に行うことができます。 • クラスターのノードの利用再開を必要とする場合は、ノードを強制終了する方法の詳細について、サポートまでお 問い合わせください。 クラスターの古いゴシップ・プロトコルを一時的に有効にする 新バージョンをインストールした後、各ノードの最初の再起動の前に、アップグレード済みの各ノードが、アップグレー ド待機中のノードに接続できるように、古いプロトコルを有効にします。パッケージ・インストールの場合は/etc/ 14 DataStax Enterpriseのアップグレード cassandra/cassandra-env.shに、tarボール・インストールの場合はインストール場所/conf/cassandraenv.shに、以下の行を追加します。 VM_OPTS="$JVM_OPTS -Denable-old-dse-state=true" Note: DataStax Enterprise 3.2.1以降にアップグレードする場合は不要です。 クラスター全体をアップグレードした後、新しいプロトコルを使用できるように各ノードの上記の行を削除し、2回目の ローリング再起動を実行します。 EverywhereStrategyを使用するためにdse_systemキースペースを手動で更新する 旧バージョンからアップグレードする場合、最初にアップグレードしたノードはEverywhereStrategyを使用する ためにdse_systemを自動的に変更し、nodetool repair dse_systemの実行を試みます。アップグレード 中に他のノードがダウンしている場合、この操作は失敗する可能性があります。エラーまたは警告がないか、/var/ log/cassandra/system.logを確認してください。自動切り替えが失敗した場合、すべてのノードが起動して から、dse_system keyspaceをEverywhereStrategyに手動で更新します。cqlshで以下のように入力しま す。 ALTER KEYSPACE dse_system WITH replication = {'class':'EverywhereStrategy'}; 次に、すべてのノードで以下のコマンドを入力します。 $ nodetool repair dse_system バージョン3.0.xからのアップグレード About this task DSE 3.0.xから最新バージョンにアップグレードするには、以下の手順に従います。 Analyticsノード クラスターのアップグレード時に、Hadoopインターフェイスを通じて作成されたカラム・ファミリーの一部が、データを 含んでいるように見えないことがあります。アップグレード・プロセスを完了すると、データが再び見えるようになりま す。 パーティショナー 以前のファイルのパーティショナー設定を新しいファイルにマージします。すでに使用していた場合を除き、新しい ファイルのCassandra 1.2のデフォルトのパーティショナー・オプション、Murmur3Partitionerを使用しないで以前の ファイルのパーティショナーに書き換えてご使用ください。 CQL 3 すべてのノードがアップグレードされ、スキーマの不一致が解決されるまで、CQL 3クエリーを発行しないでください。 セキュリティ上の推奨事項 クライアントとノード間のSSLを有効にするclient_encryption_optionsは、3.1.2より、dse.yamlから除外 されました。クライアントとノード間のSSLを有効にするには、cassandra.yamlファイルのオプションとして設定し ます。 アップグレードする前に、DataStax Enterpriseのこれらのセキュリティ機能を使用している場合 は、cassandra.yamlファイルのレプリケーション・ストラテジおよびオプションを調整し、dse_authキースペース のレプリケーション係数を1より大きく構成します。 15 DataStax Enterpriseのアップグレード • • Kerberos • 内部認証 オブジェクト・パーミッション管理（内部権限） クラスターの各ノードのdse_authのレプリケーション係数を調整します。cassandra.yamlファイルを更新して ノードを再起動した後、nodetool repairを実行して、パーティショナーにより返される、キースペースの最初の範 囲をリペアします。 nodetool repair dse_auth -pr 完了までにかかる時間は、ほんの数秒です。 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の値に変更し、後述するロー リング再起動を実行します。 Note: 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 Note: 16 DataStax Enterpriseのアップグレード auth_replication_strategyおよびreplication_factorのどちらも無効にしていない場合 は、エラーが表示されます。 エラーの修正方法の詳細については、「DataStax Enterprise 3.2.5リリー ス・ノートの問題点」を参照してください。 3. 任意で、system_authキースペースのレプリケーション係数を調整します。通常、このキースペースのデータは 少量であり、クラスター間でレプリケートされるままにしておいても、比較的負担が少なくて済みます。 SSTableのアップグレード 各ノードを再起動した後、SSTableのアップグレードが必要な場合があります。以下のような場合は、SSTableのアッ プグレードを実施します。 • カウンター・カラムを使用している場合 • Cassandra 1.0.x以前からアップグレードする場合 • Cassandra 1.0.x以前を使用しているDataStax Enterpriseバージョンからアップグレードする場合 以下の操作の前にはSSTableをアップグレードします。 • ムーブ • リペア • ブートストラップ これらの操作はクラスター内のSSTableをコピーするものであり、またディスク上のフォーマットはメジャー・バージョ ンで変更される可能性があるため、DataStaxでは、今後のSSTableの非互換性の可能性を回避するため、現時点 でSSTableをアップグレードすることを推奨します。 • tarボール：インストール場所/bin/nodetool -h upgradesstables • パッケージまたはAMI：nodetool -h upgradesstables vnode DataStaxでは、vnode（仮想ノード）は、純粋なCassandraワークロードを処理するデータ・センター でのみ使用することを推奨します。AnalyticsまたはSolrワークロードを処理するデータ・センターの場 合、cassandra.yamlのnum_tokensを1に設定することにより、vnodeを無効にする必要があります。 Solr アップグレード後にSolrノードの構成を変更する場合は、「Solr型マッピング・バージョンの構成」で説明しているよう に、型マッピングを正しく設定してください。 予想されるエラー・メッセージ DataStax Enterprise 3.0.xからアップグレードする場合、ローリング・アップグレード時に以下のような例外がログに 含まれていることがあります。これらのエラー・メッセージは無視してください。 ERROR 15:36:54,908 Exception in thread Thread[GossipStage:1,5,main ] java.lang.NumberFormatException:For input string:"127605887595351923798765477786913079296" . . . Cassandra 1.2ノードをアップグレードする場合、ノードが新しいsystem_authキースペースにミューテーションをプッ シュしようとしていることに関連する以下のエラー・メッセージを無視できます。 ERROR [WRITE-/192.168.123.11] 2013-06-22 14:13:42,336 OutboundTcpConnection.java (line 222) error writing to /192.168.123.11 java.lang.RuntimeException:Can't serialize ColumnFamily ID 2d324e48-3275-3517-8dd5-9a2c5b0856c5 to be used by version 5, because int <-> uuid mapping could not be established 17 DataStax Enterpriseのアップグレード (CF was created in mixed version cluster). at org.apache.cassandra.db.ColumnFamilySerializer.cfIdSerializedSize(ColumnFamilySerializer Solrノードをアップグレードする場合、以下のエラーを無視できます。 ERROR 00:57:17,785 Cannot activate core:ks.cf_10000_keys_50_cols ERROR 00:57:17,786 <indexDefaults> and <mainIndex> configuration sections are discontinued. Use <indexConfig> instead. ERROR 01:29:55,145 checksum mismatch in segments file (resource: ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/ solr.data/ks. cf_10000_keys_50_cols/index/segments_6" ))) ERROR 01:29:55,145 Solr index ks.cf_10000_keys_50_cols seems to be corrupted: please CREATE the core again with recovery = true to start reindexing data. ERROR 01:29:55,145 Cannot activate core:ks.cf_10000_keys_50_cols ERROR 01:29:55,146 checksum mismatch in segments file (resource:ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/solr.data/ks. cf_10000_keys_50_cols/index/segments_6" ))) org.apache.lucene.index.CorruptIndexException:checksum mismatch in segments file (resource:ChecksumIndexInput (MMapIndexInput ( path = "/var/lib/cassandra/data/solr.data/ks.cf_10000_keys_50_cols/index/ segments_6" ))) ノードの使用再開 過去72時間以内にノードを使用廃止した場合： • 72時間が経過するまで、ノードを使用再開しないでください。 • 72時間後にノードを使用再開する必要がある場合は、nodetool gossipinfoを実行します。STATUS行を チェックして、使用廃止したノードのトークンが存在しないことを確認します。存在しない場合は、ノードが削除さ れているため、ノードの使用再開を安全に行うことができます。 • クラスターのノードの利用再開を必要とする場合は、ノードを強制終了する方法の詳細について、サポートまでお 問い合わせください。 クラスターの古いゴシップ・プロトコルを一時的に有効にする 新バージョンをインストールした後、各ノードの最初の再起動の前に、アップグレード済みの各ノードが、アップグレー ド待機中のノードに接続できるように、古いプロトコルを有効にします。パッケージ・インストールの場合は/etc/ cassandra/cassandra-env.shに、tarボール・インストールの場合はインストール場所/conf/cassandraenv.shに、以下の行を追加します。 VM_OPTS="$JVM_OPTS -Denable-old-dse-state=true" Note: DataStax Enterprise 3.2.1以降にアップグレードする場合は不要です。 クラスター全体をアップグレードした後、新しいプロトコルを使用できるように各ノードの上記の行を削除し、2回目の ローリング再起動を実行します。 EverywhereStrategyを使用するためにdse_systemキースペースを手動で更新する 旧バージョンからアップグレードする場合、最初にアップグレードしたノードはEverywhereStrategyを使用する ためにdse_systemを自動的に変更し、nodetool repair dse_systemの実行を試みます。アップグレード 中に他のノードがダウンしている場合、この操作は失敗する可能性があります。エラーまたは警告がないか、/var/ log/cassandra/system.logを確認してください。自動切り替えが失敗した場合、すべてのノードが起動して 18 DataStax Enterpriseのアップグレード から、dse_system keyspaceをEverywhereStrategyに手動で更新します。cqlshで以下のように入力しま す。 ALTER KEYSPACE dse_system WITH replication = {'class':'EverywhereStrategy'}; 次に、すべてのノードで以下のコマンドを入力します。 $ nodetool repair dse_system バージョン3.1.xからのアップグレード About this task DSE 3.1.xから最新バージョンにアップグレードするには、以下の手順に従います。 クラスターの古いゴシップ・プロトコルを一時的に有効にする 新バージョンをインストールした後、各ノードの最初の再起動の前に、アップグレード済みの各ノードが、アップグレー ド待機中のノードに接続できるように、古いプロトコルを有効にします。パッケージ・インストールの場合は/etc/ cassandra/cassandra-env.shに、tarボール・インストールの場合はインストール場所/conf/cassandraenv.shに、以下の行を追加します。 VM_OPTS="$JVM_OPTS -Denable-old-dse-state=true" Note: DataStax Enterprise 3.2.1以降にアップグレードする場合は不要です。 クラスター全体をアップグレードした後、新しいプロトコルを使用できるように各ノードの上記の行を削除し、2回目の ローリング再起動を実行します。 EverywhereStrategyを使用するためにdse_systemキースペースを手動で更新する 旧バージョンからアップグレードする場合、最初にアップグレードしたノードはEverywhereStrategyを使用する ためにdse_systemを自動的に変更し、nodetool repair dse_systemの実行を試みます。アップグレード 中に他のノードがダウンしている場合、この操作は失敗する可能性があります。エラーまたは警告がないか、/var/ log/cassandra/system.logを確認してください。自動切り替えが失敗した場合、すべてのノードが起動して から、dse_system keyspaceをEverywhereStrategyに手動で更新します。cqlshで以下のように入力しま す。 ALTER KEYSPACE dse_system WITH replication = {'class':'EverywhereStrategy'}; 次に、すべてのノードで以下のコマンドを入力します。 $ nodetool repair dse_system DataStax Enterprise 4.0へのアップグレード DSE 4.0.xにアップグレードするには、以下の手順に従います。 開始する前に： DSE 4.0にアップグレードする前にJava 7以降をインストールしておく必要があります。 DSE 4.0.xの推奨アップグレード・パスは、以下のバージョンのいずれかに最初にアップグレードすることです。 • • • DataStax Enterprise 3.2.5以上 DataStax Community 1.2.16 Cassandra 2.0.x アップグレードが成功した後、（アップグレードの詳細の説明に従い）sstablesのアップグレードを実施 し、sstableのアップグレード終了後4.0.xへのローリング・アップグレードを実行します。 19 DataStax Enterpriseのアップグレード Note: 以前Cassandra 1.2.xを含むDSEのバージョンでsstableをアップグレードした場合であって も、DSE4.0にアップグレードする前にsstableのアップグレードが必要です。 Note: DSE 4.0.0からアップグレードする場合でSolrノードが含まれている場合は、「DataStax Enterprise 4.0.0からのアップグレード」の手順を確認してください。 また、多くのバージョンのアップグレードには、固有の制限があるか、特別な手順が必要な場合があります。以下の表 で現在のバージョンを探し、リンク先のページの手順に従います。 現在のバージョン アップグレード手順 DSCバージョ ン1.2.16以前 DSC 1.2.16にアップグレードし、「DataStax CommunityからDataStax Enterpriseへの アップグレード」の手順に従います DSEバージョン3.2以 前 DataStax Enterprise 3.2へのアップグレード DataStax 3.2.0〜3.2.4 「アップグレード手順の詳細」に従ってDSE 3.2.5以上に更新し、「バージョン3.2.5からの アップグレード」の手順に従います 3.2.5以上 バージョン3.2.5からのアップグレード 4.0.0 DataStax Enterprise 4.0.0からのアップグレード バージョン3.2.xからのアップグレード DataStax Enterprise 3.2.xからのアップグレードの手順 cassandra.yamlのサポート対象外オプションを除外する 各ノードのcassandra.yamlで、以下のオプションを削除またはコメント化します。 # auth_replication_options:# replication_factor: 1 これらのオプションはDataStax Enterpriseでサポートされなくなりました。 Cassandra 2.0アップグレードの変更 DSE 4.0.xにはCassandra 2.0.xが含まれています。Cassandra 2.0の変更点の詳細については、「アップグレード への影響のある変更」を参照してください。 Procedure 1. 各ノードでノードツールを使用してsstablesをアップグレードします。 $ nodetool upgradesstables Note: 以前Cassandra 1.2.xを含むDSEのバージョンでsstableをアップグレードした場合であって も、DSE4.0にアップグレードする前にsstableのアップグレードが必要です。 2. 「アップグレード手順の詳細」の説明に従ってDSE 4.0にアップグレードします。 20 DataStax Enterpriseのアップグレード DataStax Enterprise 4.0.0からのアップグレード DSE 4.0.0からのアップグレードの手順。 About this task DSE 4.0.0の不具合のため、Searchノードを持つクラスターのDSE 4.0.0からDSE 4.0.xへのアップグレードには、 データ喪失を回避するための特別な手順が必要です。 Note: DSE 4.0.0より前のバージョンからのアップグレードは、この不具合による影響を受けません。 Procedure 1. ノードを停止せずに、クラスター内の各ノードをドレーンします（nodetool drain）。 2. Solrコアを再度読み込みます。 以下の例で、Solrコアはwiki.solrで、ローカル・ホストのポート8983で実行されています。 $ curl -X POST "http://127.0.0.1:8983/solr/admin/cores? action=RELOAD&name=wiki.solr&reindex=false&deleteAll=false" 3. クラスターをアップグレードします。 4. Solrコアのインデックスを再作成します。 以下の例で、Solrコアはwiki.solrで、ローカル・ホストのポート8983で実行されています。 $ curl -X POST "http://127.0.0.1:8983/solr/admin/cores? action=RELOAD&name=wiki.solr&reindex=true DataStax Enterprise 4.5へのアップグレード DSE 4.5にアップグレードするには、以下の手順に従います。 推奨アップグレード・パスは、最初にDSE 4.0.xにアップグレードし、次に「一般的なアップグレード手順」に従っ てDSE 4.5にアップグレードすることです。 DataStax AMIのアップグレード About this task アップグレードする前に、必ずバックアップを取得します。アップグレード後、NEWS.txtを確認し、最新のアップグ レード情報を確認します。 Note: クラスターにAnalyticsノードが含まれる場合は、最初にジョブ・トラッカー・ノードのアップグレードおよ び再起動を行います。 Procedure 1. 各ノードで、DataStaxリポジトリが/etc/apt/sources.listにリストされていることを確認します。 $ deb http://username:[email protected]/enterprise stable main ここで、usernameおよびpasswordは、登録確認の電子メールに記載されているDataStaxアカウント認証情報 です。 2. 必要に応じて、DataStaxリポジトリ・キーをapt-keyに追加します。 21 DataStax Enterpriseのアップグレード $ curl -L http://debian.datastax.com/debian/repo_key | sudo apt-key add 3. 各ノードで以下のコマンドを実行します。 $ sudo apt-get update $ sudo apt-get install dse-full 4. cassandra.yamlファイル、および/etc/dseディレクトリーで変更された可能性のあるその他のプロパティ・ ファイルの新しいバージョンと古いバージョンを比較します。 アップグレードをインストールすると、cassandra.yamlのバックアップが/etc/dse/cassandraディレクト リーに作成されます。このコピーを使用し、2つの構成ファイルを比較し、必要に応じて変更します。 a) 以下の構成ファイルの差分を確認します。 • 古いインストールのcassandra.yaml 新しいDSE 3.xのcassandra.yaml b) 古いcassandra.yamlから新しいDSE 3.xのcassandra.yamlに、手動で構成をマージします。 • 古いファイルから新しいファイルにスニッチ設定を追加しないでください。cassandra.yamlの新しいデフォ ルトのスニッチはcom.datastax.bdp.snitch.DseDelegateSnitchですが、以前のバージョンのデ フォルトのスニッチはcom.datastax.bdp.snitch.DseSimpleSnitchです。 以前のリリースからプロパティ・ファイルをコピーし、新しいリリースのファイルを上書きしないでください。この ような操作を試みたユーザーから、問題が発生したことが報告されています。 5. 「スニッチの変換」の説明に従ってスニッチ設定を構成します。 6. 必要に応じて、新しいDSEバージョンとの互換性のない、python-cql、Hector、PycassaなどのCQLドライバーお よびクライアント・ライブラリをアップグレードします。CQLドライバーおよびクライアント・ライブラリは、DataStaxダ ウンロード・ページからダウンロードできます。 7. nodetool drainを実行し、コミット・ログをフラッシュします。 8. ノードを再起動します。 $ sudo service dse restart 9. クライアント・アプリケーションを再起動します。 アップグレードのロールバック このセクションでは、DSEを以前のバージョンに戻す方法について説明します。 パッケージ・インストールから以前のバージョンに戻す パッケージ・インストールしたDSEを以前のバージョンに戻す方法。 Procedure 1. すべてのDSEパッケージをアンインストールします。 • DebianおよびUbuntu • # apt-get remove dse-full RHELおよびCentOS # yum remove dse-full 22 DataStax Enterpriseのアップグレード 2. カラム・ファミリーごとにSSTableファイルをスナップショット・ディレクトリーからデータ・ディレクトリーにコピーする ことにより、アップグレード前に取得したスナップショットを復元します。複数のスナップショットがある場合は、タイ ムスタンプを確認して最新のスナップショットを探します。 以下の例で、スナップショット・ディレクトリー はdata_directory_location/keyspace_name/table_name/snapshots/snapshot_name、 データ・ディレクトリーは/dataです。 # cd data_directory_location/keyspace_name/table_name/ snapshots/snapshot_name # cp -R * data_directory_location/keyspace_name/table_name 3. 以前のバージョンのDSEのドキュメントの説明に従い、そのバージョンを再インストールします。 4. Solrを使用している場合は、「インデックスの完全な再作成」の説明に従ってインデックスを再構築します。 tarボール・インストールから以前のバージョンに戻す tarボール・インストールから、以前のバージョンのDSEに戻す方法。 Procedure 1. 現在のインストール・ディレクトリーの名前を変更します。 # mv dse4.0 dse4.0.bak 2. カラム・ファミリーごとにSSTableファイルをスナップショット・ディレクトリーからデータ・ディレクトリーにコピーする ことにより、アップグレード前に取得したスナップショットを復元します。複数のスナップショットがある場合は、タイ ムスタンプを確認して最新のスナップショットを探します。 以下の例で、スナップショット・ディレクトリー はdata_directory_location/keyspace_name/table_name/snapshots/snapshot_name、 データ・ディレクトリーは/dataです。 # cd data_directory_location/keyspace_name/table_name/ snapshots/snapshot_name # cp -R * data_directory_location/keyspace_name/table_name 3. 古いcassandra.yamlファイルを、古いインストール・ディレクトリーから新しいディレクトリーにコピーします。 # cp dse4.0.bak/resources/cassandra/config/conf/cassandra.yaml <新しいインス トール・ディレクトリー>/resources/cassandra/config/conf/ 4. 以前のバージョンのDSEのドキュメントの説明に従い、そのバージョンを再インストールします。 5. Solrを使用している場合は、「インデックスの完全な再作成」の説明に従ってインデックスを再構築します。 23 DataStax CommunityからDataStax Enterpriseへのアップグレード DataStax CommunityからDataStax Enterpriseへのアップグ レード About this task DataStax CommunityバージョンからDataStax Enterprise 3.2以降にアップグレードする前に、各ノードで以下の 手順を実行します。 Procedure 1. DataStax Communityのアンインストール DataStax CommunityのDebianまたはRPMパッケージをインストール済みである場合は、構成ファイルのバック アップを取得した後、セットアップおよびインストールを実行する前に、DataStax Communityを削除する必要が あります。 • Debianパッケージの場合： $ sudo apt-get remove dsc cassandra $ sudo apt-get autoremove ノード上のCassandraをまだシャットダウンしていなければ、このアクションによりシャットダウンされます。 • RPMパッケージの場合： $ rpm -e apache-cassandra1 –noscripts 古い Cassandraの構成ファイルの名前は cassandra.yaml.rpmsaveに変更されます。 warning:/etc/cassandra/default.conf/cassandra.yaml saved as /etc/cassandra/default.conf/cassandra.yaml.rpmsave 2. スニッチの変換 スニッチは、cassandra.yamlではなくdse.yamlファイルに設定しま す。dse.yamlは、install_location/resources/dse/confディレクトリーにあります。 以下の表で、プロパティの変換方法について説明します。 24 endpoint_snitch URL アップグレード・タスク org.apache.cassandra.locator.SimpleSnitch DseDelegateSnitchは、cassandra.yamlファ イルで設定されているままにしておいて、新 しいdse.yamlファイルにあるデフォルト のdelegated_snitchは変更しません。 org.apache.cassandra.locator.PropertyFileSnitch 古いインストール先からcassandratopology.propertiesファイル をinstall_location/ resources/ cassandra/confにコピーしてペーストし、新 しいプロパティ・ファイルを上書きします。新し いdse.yamlファイルのdelegated_snitch設定 をorg.apache.cassandra.locator.PropertyFileSnitc 設定します。 DataStax CommunityからDataStax Enterpriseへのアップグレード endpoint_snitch URL アップグレード・タスク その他のスニッチURL 新しいdse.yamlファイルのデフォルト のdelegated_snitchを現在のスニッチ設定に変更し ます。 デフォルトのdelegated_snitch（com.datastax.bdp.snitch.DseSimpleSnitch）は、新し いdse.yamlファイルに指定されています。 25 Cassandraのアップグレード Cassandraのアップグレード このセクションでは、最新バージョンのCassandraにアップグレードする方法を説明します。 バージョンに関する制約事項 Cassandra 2.0.xの制約事項 Cassandra 2.0.xへのアップグレードはCassandra 1.2.9以降のCassandraである必要があります。Cassandra 2.0とCassandra1.2.9より前のバージョンにはネットワークやSSTableの互換性がありません。お使い のCassandraのバージョンが1.2.9より前のものであり、ローリング再起動を実行する場合は、最初にクラスター全体 を1.2.9以降の1.2.xにアップグレードしてから、Cassandra 2.0にアップグレードしてください。 ベスト・プラクティス 一般的なアップグレード手順 1. アップグレードを実行する前に、すべてのキースペースのスナップショットを取得します。 必要に応じて、前のバージョンにロールバックすることもできます。Cassandraでは前のバージョンで作成された データ・ファイルを読み取ることができますが、その逆はできないことがあります。スナップショットは、特にJNAを インストールしてあれば高速に取得でき、利用中のデータ・ファイルのコンパクションを再開するまでは、ディスク 領域を実際には消費しません。 2. Hectorクライアント、Pycassaクライアントなどのクライアント・ドライバーに新しいバージョンとの互換性があるこ とを確認します。 3. アップグレード方法の詳細については、NEWS.txtのアップグレード方法に関するセクションを確認してください。 4. このリリースの変更点と修正点について十分理解してください。 完全なリストはCHANGES.txtに記載されています。さまざまな機能に関する一般的なアップグレードのアドバイ スは、NEWS.txtに記載されています。 5. 既存のCassandra サービスのシャットダウンを実行する前に、nodetool drainを実行します。これにより、カウン ター・データのオーバーカウントが避けられ、アップグレード後の再起動も迅速化されます。 6. 「アップグレード手順の詳細」の手順に従います。 7. 問題がないか、ログ・ファイルを見ます。 8. アップグレードを済ませ、すべてのCassandraプロセスの再起動を実行した後、クライアント・アプリケーションを 再起動します。 9. クラスターのすべてのノードのアップグレードを実行した後、既存のノードをvnodeへアップグレードすることを検 討します。 vnodeへのアップグレードは任意ですが、いくつかの重要なメリットがあります。「既存の実稼働クラスターで仮想 ノードを有効化」を参照してください。 アップグレードを行う前に、以下のベスト・プラクティスに従います。 • アップグレードを実行する前に、すべてのキースペースのスナップショットを取得します。 必要に応じて、前のバージョンにロールバックすることもできます。Cassandraでは前のバージョンで作成された データ・ファイルを読み取ることができますが、その逆はできないことがあります。スナップショットは、特にJNAを 26 Cassandraのアップグレード インストールしてあれば高速に取得でき、利用中のデータ・ファイルのコンパクションを再開するまでは、ディスク 領域を実際には消費しません。 • アップグレード方法に関する新しい情報については、NEWS.txtを確認してください。 NEWS.txtは、Apache Cassandra githubサイトにあります。 • このリリースの変更点と修正点について十分理解してください。 完全なリストはCHANGES.txtに記載されています。さまざまな機能に関する一般的なアップグレードのアドバイ スは、NEWS.txtに記載されています。 アップグレード手順の詳細 About this task このセクションでは、クラスターのノードをアップグレードする手順を説明します。 Before you begin • Cassandra 2.xには、最新バージョンのJava SE Runtime Environment (JRE) 7が必要です。 • すべてのデッド・ノードは排除する必要があります。 クラスターのノードがダウンしている場合はアップグレードしないでください。デッド・ノードを排除するには、 nodetool removenodeコマンド（以前のリリースのnodetool removetoken）を使用します。 • 古いcassandra.yamlでindex_intervalの値を確認し、アップグレード時に別のデフォルト値をテーブルに適 用する場合はそれを変更します。Cassandra 2.0以降では、index_intervalがcassandra.yamlから移動 し、テーブル・プロパティとなっています。 アップグレード時に、古いcassandra.yamlで定義した値が、アップグレードされたテーブルのデフォルトのプロ パティとして適用されます。アップグレード後、CQLを使用してこのプロパティを変更できます。 • クラスターでvnodeを使用していない場合は、各ノードの新しいcassandra.yamlファイルの中でvnodeを無効に してからローリング再起動を実行してください。 Cassandra 2.0.xでは、仮想ノード（vnode）はデフォルトで有効になっています。アップグレードを実行する前に バージョン2.0.xのvnodeを無効にします。 1. cassandra.yamlファイルの中で、num_tokensを1に設定します。 2. initial_tokenプロパティのコメントを解除し、1に設定するか、またはマルチノード・クラスターの場合 は、生成されたトークンの値に設定します。 Procedure 1. ノードを停止します。 2. 構成ファイルのバックアップを取得します。 製品のインストール方法によっては、インストール時にこれらのファイルがデフォルト値で上書きされてしまう可能 性があります。構成のバックアップを取得したら、現在のインストールの種類に応じた適切なインストール手順に 従います。 3. 新しいバージョンのCassandraをインストールします。 • DebianまたはUbuntu • RHELまたはCentOS • tarボール 27 Cassandraのアップグレード 4. 新しいバージョンの製品を構成します。 構成ファイルから取得したバックアップを使用して、以前に利用していた変更を、新バージョンの新しい構成ファ イルにマージします。構成オプションはたびたび変更されるため、必ず「バージョンに関する制約事項」で、構成に 関連する追加の手順および変更を確認してください。 5. ノードを起動します 6. メジャー・バージョンからアップグレードする場合（たとえば1.2 から2.0へのアップグレード）、またはメジャー・ポ イント・リリースからアップグレードする場合（たとえばCassandra 2.0から2.1へのアップグレード）は、各ノード のsstablesをアップグレードします。 $ nodetool upgradesstables 7. 警告、エラー、および例外がないか、ログをチェックします。 8. クラスターの各ノードについて手順を繰り返します。 クラスターの一部が部分的にアップグレードされている状態での一般的な制限事項： • nodetool repairを実行しないでください。 • 新しい機能を使用しないでください。 • ローリング再起動中に、DDL、TRUNCATEのような種類のクエリーを実行しないでください。 DebianまたはUbuntu About this task 新しいバージョンを取得して、古いcassandra.yamlファイルのカスタマイズした部分を新しいファイルにマージ し、アップグレードを完了するには、以下の手順に従います。 Procedure 1. 古いインストールのcassandra.yamlファイルを安全な場所に保存します。 2. Cassandraの各ノードで、新しいバージョンをインストールします。 $ sudo apt-get install dsc20 3. cassandra.yamlの古いファイルと新しいファイルを開き、差分を確認します。 4. 古いファイルから新しいファイルに、パーティショナー設定などの差分を手動で統合します。 新しいcassandra.yamlのデフォルトのパーティショナー設定は使用しないでください。このリリース でMurmur3Partitionerに変更されたためです。Murmur3Partitionerは、新しいクラスターのみに使用 できます。クラスターへのデータの追加後、パーティショナーを変更するにはテーブルを作り替える必要がありま すが、それは現実的ではありません。新しいcassandra.yamlファイルでも、古いパーティショナー設定を使用して ください。 5. ファイルをcassandra.yamlという名前で保存します。 RHELまたはCentOS About this task 古いインストールを削除し、古いcassandra.yamlファイルのカスタマイズした部分を新しいファイルにマージし、 アップグレードを完了するには、以下の手順に従います。 Procedure 1. Cassandraの各ノードで古いインストールを削除します。例： 28 Cassandraのアップグレード $ sudo yum remove dsc12 2. 新しいバージョンをインストールします。 $ sudo yum install dsc20 インストーラーにより、/etc/cassandra/default.conf/にcassandra.yaml.rpmnewファイルが作成 されます。 3. cassandra.yamlの古いファイルと新しいファイルを開き、差分を確認します。 4. 古いファイルから新しいファイルに、パーティショナー設定などの差分を手動で統合します。 古いリリースでMurmur3Partitionerが使用されている場合を除き、新しいcassandra.yamlでデフォル トのパーティショナー設定Murmur3Partitionerを使用しないでください。Murmur3Partitionerは、新し いクラスターのみに使用できます。クラスターへのデータの追加後、パーティショナーを変更するにはテーブルを 作り替える必要がありますが、それは現実的ではありません。新しいcassandra.yamlファイルでも、古いパー ティショナー設定を使用してください。 5. ファイルをcassandra.yamlという名前で保存します。 tarボール About this task バイナリーtarボールをダウンロードして解凍し、古いcassandra.yamlファイルのカスタマイズした部分を新しい ファイルにマージし、アップグレードを完了するには、以下の手順に従います。 Procedure 1. 古いインストールのcassandra.yamlファイルを安全な場所に保存します。 2. 各ノードで、Cassandra Webサイトのdownloads sectionからバイナリーtarボールのパッケージをダウンロードし て解凍します。 3. 新しいインストール先で、書き込むためにcassandra.yamlを開きます。 4. 古いインストール先で、cassandra.yamlを開きます。 5. cassandra.yamlの古いファイルと新しいファイルの差分を確認します。 6. 古いファイルから新しいファイルに、パーティショナー設定などの差分を手動でマージします。 新しいcassandra.yamlのデフォルトのパーティショナー設定は使用しないでください。このリリース でMurmur3Partitionerに変更されたためです。Murmur3Partitionerは、新しいクラスターのみに使用 できます。クラスターへのデータの追加後、パーティショナーを変更するにはテーブルを作り替える必要がありま すが、それは現実的ではありません。新しいcassandra.yamlファイルでも、古いパーティショナー設定を使用 してください。 7. RHELまたはCentOS 5プラットフォームの場合のみ、snappy-java-1.5.0.jarをSnappyのバージョ ン1.4.1.1（こちらから入手可能）に置き換えます。 $ rm lib/snappy-java-1.0.5.jar $ cd lib $ curl -OL https://snappy-java.googlecode.com/files/snappy-java-1.0.4.1.jar アップグレードへの影響のある変更 Cassandra 2.1.xへのアップグレードに影響を与える可能性のある変更は以下のとおりです。 29 Cassandraのアップグレード • CASおよびCQLの新機能（DROP COLUMNなど）は、セル・タイムスタンプがエポック以来の経過マイクロ秒数で あることを前提としています。 他のなんらかのソースに基づくクライアント指定タイムスタンプを使用している場合は、これらの機能を使用しな いでください。 • 不明なキースペース・レプリケーション・オプションは使用できなくなりました。 • Cassandra 2.0以降には、CQL仕様3.1.0に基づく新しいバージョンのCQL（およびcqlsh）が含まれています。 • ALTER文およびCREATE文では、小文字のプロパティ・マップ・キーを使用します。 以前のリリースのALTER文および CREATE文で使用されているCQLプロパティ・マップ・キーは大文 字と小文字の区別がありません。たとえば、CLASSまたはclassや、REPLICATION_FACTORまた はreplication_factorが許容されていました。プロパティ・マップ・キーで大文字と小文字の区別がな いことは、他の文字列リテラルの処理との不整合が生じ、大文字と小文字の区別があるデータ・センター名 を持つNetworkTopologyStrategyプロパティ・マップの形式との互換性もありません。このリリースで は、class、replication_factorなどのプロパティ・マップ・キーは大文字と小文字の区別があります。小文 字のプロパティ・マップ・キーを以下の例に示します。 • CREATE KEYSPACE test WITH replication = { 'class' :'SimpleStrategy', 'replication_factor' :'1' }; 厳密な検証機能を持つようになったCQL定数について緩やかな検証を行うクエリーは、修正が必要になることが あります。 文字列定数としてのBLOBの使用は、BLOB定数のために廃止されています。 • vnodeは、2.0以降のcassandra.yamlでデフォルトで有効になっています。vnodeを使用しないクラスターを アップグレードする前に、vnodeを無効にしてください。 • initial_tokenを使用しない単一トークン・ノードのauto_bootstrapは、既存のトークン範囲を二分する 代わりに、ランダム・トークンを選択するようになりました。 アップグレード完了後はvnodeを使用することを推奨します。使用しない場合は、初期トークンを指定してくださ い。 • reduce_cache_sizes_at、reduce_cache_capacity_to、およ びflush_largest_memtables_atの各オプションがcassandra.yamlから削除されました。 • CacheServiceMBean.reduceCacheSizes()が削除されまし た。CacheServiceMBean.set{Key,Row}CacheCapacityInMB()を使用してください。 • cassandra.yamlのauthorityオプションが1.2.0から廃止されました。2.0からは完全に除去されまし た。authorizerオプションを使用してください。 • index_intervalがCQLテーブル・プロパティとなりました。アップグレードした後は、ALTER TABLEを使用し て、index_intervalの値を変更できます。 アップグレード時に、Cassandraは、古いcassanda.yamlに定義されている値を、アップグレード後のテーブル のデフォルトとして使用します。 • 30 廃止されたnative_transport_min_threadsオプションが、cassandra.yamlから除去されました。 OpsCenterのアップグレード OpsCenterのアップグレード アップグレードする前に、CassandraまたはDataStax Enterpriseのバージョンが、アップグレードす るOpsCenterバージョンと互換性があることを確認します。 OpsCenterバージョン Cassandraバージョン DataStax Enterpriseバージョン 5.0 1.2, 2.0, 2.1 3.1.x、3.2.x、4.0.x、4.5.x 4.1 1.1, 1.2, 2.0 3.0.x、3.1.x、3.2.x、4.0.x 4.0 1.1, 1.2, 2.0 3.0.x、3.1.x、3.2.x 3.2 1.1, 1.2 2.x、3.0.x、3.1.x 3.1 1.0, 1.1, 1.2 1.0、2.x、3.0 3.0 1.0, 1.1, 1.2 1.0、2.x、3.0.x 2.1 0.8, 1.0, 1.1 1.0, 2.0 2.0 0.8, 1.0, 1.1 1.0, 2.0 1.4.x 0.7, 0.8, 1.0, 1.1 1.0, 2.0 前のバージョンからOpsCenter 5.0をアップグレードするには、このセクションの情報を使用します。 パッケージ・インストールのアップグレード 新しいOpsCenter 5.0パッケージのインストール方法、およびopscenterdデーモンの再起動方法について説明しま す。 About this task OpsCenter5.0をアップグレードするには： Procedure 1. OpsCenterデーモン・ホストで適切なコマンドを実行し、パッケージを更新します。 • DebianまたはUbuntu • # apt-get update RHELまたはCentOS # yum clean all 2. アップグレードされたOpsCenterパッケージをインストールします。 • DebianまたはUbuntu： • # apt-get install opscenter RHELまたはCentOS： # yum install opscenter 31 OpsCenterのアップグレード 3. パッケージ・マネージャーによってopscenter.confに関する選択肢が表示された場合は、現在インストールされて いるバージョンを維持するように選択します。 4. OpsCenterデーモンを再起動します。 # service opscenterd restart 5. RHELまたはCentOS上で、アップグレード後のOpsCenterの起動時にpyOpenSSLでエラーが発生した場合 は、OpsCenterをアンインストールし、/usr/share/opscenter/libディレクトリーを削除してから再インス トールします。 a) OpsCenterをアンインストールします。 DebianまたはUbuntu # apt-get remove opscenter RHELまたはCentOS # yum uninstall opscenter b) /usr/share/opscenter/libディレクトリーを削除します。 # rm -rf /usr/share/opscenter/lib c) OpsCenterを再インストールします。 DebianまたはUbuntu # apt-get install opscenter RHELまたはCentOS # yum install opscenter tarボール・インストールのアップグレード About this task Procedure 1. 新しいtarボールをダウンロードして解凍します。 2. 古いtarボール・インストール先ディレクトリーの以下のファイルおよびディレクトリーを新しいインストール先ディレ クトリーにコピーします。 conf/clusters/* conf/event-plugins/* conf/install_id conf/log4j.properties conf/opscenterd.conf conf/ssl.conf ssl/* 3. opscenterdインスタンスを停止し（実行中である場合）、新しいtarボール・インストール先ディレクトリーから起 動します。 4. GUIから、または新しいtarボールから手動でインストールすることにより、エージェントをアップグレードします。 32 OpsCenterのアップグレード エージェントのアップグレード About this task 新しいリリースのためにDataStaxエージェントのアップグレードが必要な場合は、OpsCenterコンソールの上部近く に「Fix」リンクが表示されることで、アップグレードするよううながされます。 Procedure アップグレードされたエージェントのインストール方法の詳細については、「OpsCenterエージェントのインストー ル」を参照してください。 tarボールから tarボールを使用して手動でエージェントをアップグレードする場合は、新しいagent.tar.gzをすべてのノードにコピー して解凍してから、 古いエージェントtarボール・ディレクトリーの以下のファイルを新しいディレクトリーにコピーしま す。 conf/* ssl/* 33 DataStaxのドキュメントを使用するためのヒント DataStaxのドキュメントを使用するためのヒント ドキュメントのナビゲート ドキュメントをナビゲートするには、左側のナビゲーション・バーの目次または検索を使用します。さらに以下のコント ロールを使用できます。 左側のナビゲーションの表示・非表示を切り替えます。 目次に表示されている前のトピックに戻るか、先のトピッ クに進みます。 検索語のハイライト表示を切り替えます。 ページを印刷します。 ドキュメントのツイートを表示し、フィードバックを提供し ます。 つかんで動かすことでナビゲーション・ペインのサイズを 調整します。 ブックマークが付いた見出しに表示されます。［¶］を右ク リックすると、リンクが表示されます。 CQL文とnodetoolのオプションの凡例の表示・非表示 を切り替えます。 その他のリソース 詳細とサポートについては、以下をご覧ください。 34 • ドキュメントのホームページ • データシート • ウェビナー • ホワイトペーパー • 開発者のブログ • サポート
© Copyright 2024