DataStax Enterprise 5.1.xパッチ・リリースのアップグレード

パッチ(ポイント)リリース間のDataStax Enterprise 5.1のアップグレード手順。

DataStax Enterprise 5.1.3から5.1.5にアップグレードするような、パッチ(ポイント)リリース間でのDataStax Enterprise(DSE)のアップグレードについては、この情報を確認してください。

重要: アップグレードの前にこれらの手順を読み、理解しておいてください。計画およびアップグレード手順を細かく確認しておくと、スムーズなアップグレードが保証され、不備や不満が生じるのを避けることができます。

DataStaxドライバーの変更点

DataStaxドライバーには2つのタイプがあります。

  • DataStax Enterprise用DataStaxドライバー:DSE 4.8以降用
  • Apache Cassandra用DataStaxドライバー:Apache CassandraおよびDSE 4.7以前のバージョン用
注: Apache Cassandraドライバー用のDataStaxドライバーは、DSE 5.0以降のクラスターに接続できますが、DSEドライバーにアップグレードすることを強くお勧めします。DSEドライバーでは、DataStax Enterpriseのすべての機能を使用できます。
1. アップグレードの情報は、各ドライバーのガイドに含まれています。
DataStax Enterprise用DataStaxドライバー Apache Cassandra用DataStaxドライバー
C/C++ C/C++
C# C#
Java Java
Node.js Node.js
Python Python
メンテナンス・モード・ドライバー
DataStaxでサポートされますが、新しいバージョンには重大なバグの修正のみが含まれます。
PHP PHP
Ruby Ruby
追加のドライバーのドキュメント
すべてのドライバー バージョンの互換性

DataStax EnterpriseおよびApache Cassandraの構成ファイル

構成ファイル Installer-Servicesおよびパッケージ・インストール Installer-No Servicesおよびtarボール・インストール
DataStax Enterpriseの構成ファイル
byoh-env.sh /etc/dse/byoh-env.sh install_location/bin/byoh-env.sh
dse.yaml /etc/dse/dse.yaml install_location/resources/dse/conf/dse.yaml
logback.xml /etc/dse/cassandra/logback.xml install_location/resources/logback.xml
spark-env.sh /etc/dse/spark/spark-env.sh install_location/resources/spark/conf/spark-env.sh
spark-defaults.conf /etc/dse/spark/spark-defaults.conf install_location/resources/spark/conf/spark-defaults.conf
Cassandraの構成ファイル
cassandra.yaml /etc/cassandra/cassandra.yaml install_location/conf/cassandra.yaml
cassandra.in.sh /usr/share/cassandra/cassandra.in.sh install_location/bin/cassandra.in.sh
cassandra-env.sh /etc/cassandra/cassandra-env.sh install_location/conf/cassandra-env.sh
cassandra-rackdc.properties /etc/cassandra/cassandra-rackdc.properties install_location/conf/cassandra-rackdc.properties
cassandra-topology.properties /etc/cassandra/cassandra-topology.properties install_location/conf/cassandra-topology.properties
jmxremote.password /etc/cassandra/jmxremote.password install_location/conf/jmxremote.password
Tomcatサーバーの構成ファイル
server.xml /etc/dse/resources/tomcat/conf/server.xml install_location/resources/tomcat/conf/server.xml

一般的な推奨事項

警告: TTLの期限切れのタイムスタンプは、2038年問題の影響を受けやすくなります。TTL値が長く、最大しきい値の2038-01-19T03:14:06+00:00より大きい期限切れの日付である場合、そのデータはすぐに期限切れとなり、次のコンパクションでパージされます。DataStaxでは、 気付かないうちにデータがなくならないように、DSE 5.1.7以降にアップグレードし、必要な措置を講じることを強く推奨します。(DSP-15412)。
重要: DataStaxでは、最新のDSE 5.1.12へのアップグレードを推奨しています。

OpsCenterでは、Backup Service(バックアップ・サービス)が提供されます。このサービスは、DataStax Enterpriseクラスターの企業全体のバックアップ操作と復元操作を管理します。OpsCenter 6.5以降が推奨されます。

アップグレード・プロセス中の一般的な制限事項

制限事項は、クラスターの一部が部分的にアップグレードされている状態で適用されます。クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。

アップグレード中のすべてのノードの制限事項
  • 新しい機能を有効にしないでください。
  • nodetool repairを実行しないでください。
  • ノードをブートストラップしたり、使用廃止にしたりしないでください。
  • 必要なときにSSTableをアップグレードしなかった場合、パフォーマンスが大幅に低下し、ディスク使用量が増加します。アップグレードは、SSTableがアップグレードされるまで完了しません。
注: アップグレード中、異なるバージョン上のノードでスキーマの不一致が発生する場合があります。
DSE Analytics(Spark)アップグレードの制限事項
  • すべてのノードがアップグレードされるまで、分析ジョブを実行しないでください。
  • ノードを停止して新しいバージョンをインストールする前に、すべてのSparkワーカー・プロセスを強制終了してください。
DSE Search(Solr)アップグレードの制限事項
  • スキーマを更新しないでください。
  • アップグレード中にDSE Searchノードにインデックスを付け直さないでください。
  • ローリング再起動中に、DDLTRUNCATEのような種類のクエリーを実行しないでください。
セキュリティ・アップグレードの制限事項
  • アップグレードの完了後まで、セキュリティ認証情報またはパーミッションを変更しないでください。
  • Kerberosをまだ使用していない場合は、アップグレードの前にKerberos認証を設定しないでください。最初にクラスターをアップグレードしてからKerberosをセットアップしてください。
DSE Graph
  • 通常、DSE Graphは他のワークロードとともに実行されるため、それらのワークロードについても同じアップグレードの制限事項に従ってください。
  • アップグレード中はグラフやその他のスキーマを作成したりアップデートしたりしないでください。
  • アップグレード中のGremlinやグラフ関連のエラーは無視してもかまいません。

5.1.xパッチ・リリースのアップグレードの特別な制限事項

DSE 5.1.0~5.1.5にアップグレードする際の制限事項
DSE Searchでは、バージョンが混在するクラスターのトークンフィルターが見落とされる場合があります。トークンフィルター処理が正しく行われるようにするには、すべてのノードをDSE 5.1.6以降にアップグレードします。
DSE 5.1.4にアップグレードする際の制限事項
DSE Analytics Spark JobserverではDSEのカスタム・バージョン0.7.0.125を使用します。アプリケーションでは、DataStaxリポジトリ内の互換性のあるSpark Jobserver APIを使用する必要があります。
DSE 5.1.6以降からアップグレードする場合の制限事項
DSE Analytics DSEFS権限管理は、DSE権限管理が有効になっている場合にのみ有効です。DSE権限管理が有効で、DSE権限管理が無効になっているクラスターは、5.1.6以降にアップグレードした後は、DSEFS権限管理を持ちません。DSE 5.1.6 DSEFSより前のバージョンでは、権限管理は、DSE権限管理が有効であれば有効になり、DSE権限管理を有効または無効にしてもDSEFSには影響しませんでした。
DSE 5.1.3にアップグレードする際の制限事項
  • ビュー行の活性は、フィルターが適用された複数のベース非キー・カラムと、ビューのプライマリ・キーで使用されているベース非キー・カラムに依存するため、非プライマリ・キー・ベース・カラム(CASSANDRA-10368)にフィルターを適用したマテリアライズド・ビューの作成は無効になっています。このセマンティクスは、ストレージ形式を変更しなければサポートされません(CASSANDRA-13826)。追加書き込みのみのユース・ケースの場合は、システム・プロパティ・スイッチでこの機能を使用できます。
    -Dcassandra.mv.allow_filtering_nonkey_columns_unsafe=true
  • テーブルsystem_auth.resource_role_permissons_indexは使用されなくなったため、すべてのノードが5.1.3になったら削除する必要があります。
  • nodetool repairでオプションが指定されていない場合は、リペア対象のテーブル/キースペースで既にインクリメンタル・リペアが実行されていない限り、後方互換性を保つためにインクリメンタル以外のフル・リペアがデフォルトになります。新しいテーブルでインクリメンタル・リペアを実行するには、-incオプションを使用します。
  • インクリメンタル・リペアは、その制限事項が対処されるまで、マテリアライズド・ビューまたはCDCを使用したテーブルではサポートされなくなりました。ベース・テーブルまたはマテリアライズド・ビューでトリガーされたインクリメンタル・リペアは、代わりにフル・リペアを実行します(CASSANDRA-12888)。
  • DSE 5.1.1または5.1.2からDSE 5.1.3にアップグレードする際の制限事項
    • Apache Cassandraでは、マテリアライズド・ビューのあるテーブルのカラムを削除できなくなりました。
    • マテリアライズド・ビューのタイムスタンプの計算方法が変更されました。この変更により、アップグレード後にベース・テーブルをリペアした場合に、ビューのプライマリ・キー(PK)カラムであるベース・カラムに対する古い削除がビューに反映されない可能性があります。この状態は、ベース・テーブルPKに存在しないMVプライマリ・キー(PK)カラムに対するカラムの削除(UPDATE base SET view_pk_col = null or DELETE view_pk_col FROM base)が、アップグレード前に行われず、アップグレード後にリペアされた場合にのみ発生します。このようなカラムの削除が、ベースPKではないビューPKカラムで行われた場合は、アップグレード前にすべてのノードのベース・テーブルでリペアを実行します。代わりに、アップグレード後にビューでリペアを実行することにより、潜在的な不一致を修正するか、ビューを削除して再度作成することができます。詳細については、CASSANDRA-11500を参照してください。
    • マテリアライズド・ビューで選択されていないカラムの削除(UPDATE base SET unselected_column = null or DELETE unselected_column FROM base)は、状況によっては正しくビューに反映されない場合があります。DataStaxでは、ビューで選択されていないベース・カラムの削除は、CASSANDRA-13826で修正されるまではお勧めしていません。

DSE 5.1.1から5.1.2以降の5.1.xリリースにアップグレードするための高度な準備

このセクションは、DSE 5.1.1から5.1.2以降のDSE 5.1.xリリースへのアップグレードのみに適用します。

DSE 5.0.9およびDSE 5.1.2のメッセージング・プロトコルはVERSION_3014に変更されました。スキーマの移行は正確なメッセージング・プロトコル・バージョンに依存します。アップグレード中に発生する可能性のあるスキーマの変更に対応するには、後方互換性メッセージング・プロトコルを強制的に使用します。

  1. アップグレードに、次の起動時のパラメーターを使用してノードを再起動します。
    -Dcassandra.force_3_0_protocol_version=true
    例を次に示します。
    installation_location/bin/dse cassandra -Dcassandra.force_3_0_protocol_version=true
    注: アップグレード時にはバージョンが混在しますが、既存のテーブルのカラムを追加したり削除したりしないでください。
  2. すべてのノードでアップグレードが完了したら、アップグレード手順に従って、この起動時のパラメーターを使わずにノードを再起動します。

アップグレードの準備

  1. データをバックアップします。 DataStaxでは、バージョン・アップグレードの前に、ログ、カスタム構成などのデータをバックアップすることを推奨しています。バックアップすることによって、必要に応じて前のバージョンで使用したすべてのデータに戻したり、そのデータを復元したりすることができます。
    ヒント: OpsCenterでは、Backup Service(バックアップ・サービス)が提供されます。このサービスは、DataStax Enterpriseクラスターの企業全体のバックアップ操作と復元操作を管理します。OpsCenter 6.5以降が推奨されます。
  2. 現在の製品バージョンを確認します。
    dse -v
  3. アップグレードの前に、各ノードに十分な量の空きディスク領域があることを確認してください。

    必要なディスク領域は、コンパクション戦略によって異なります。「ディスク領域」を参照してください。

  4. DataStax EnterpriseおよびApache Cassandraの変更点や機能について、よく理解しておいてください。
    • アップグレード・バージョンのDataStax Enterpriseリリース・ノートを参照し、必要なアクションをすべて完了してください。

      DSEリリース・ノートには、必要な計画、コンポーネント、変更点、拡張機能、既知の問題、および解決済みの問題が記載されています。5.15.0、および4.8

    • 任意のバージョンのアップグレードに関する一般的なアドバイス、およびApache Cassandraの新機能については、NEWS.txtに記載されています。NEWS.txtを現在ご使用のバージョンの箇所まで必ずお読みください。
    • Apache Cassandraでの変更点については、CHANGES.txtに記載されています。
    • DataStax Enterpriseの実稼働環境で認定済みのApache Cassandraの変更点については、DSEリリース・ノートに記載されています。
    • DataStaxドライバーの変更点
  5. 現在の製品バージョンを確認します。
    dse -v
  6. DSE Searchノード:
    • catalina.propertiesおよびcontext.xmlファイルがTomcat confディレクトリーにあることを確認します。これらのファイルが見つからない場合、DSEは起動しません。
      Tomcat confディレクトリーのデフォルトの場所は、インストールのタイプによって異なります。
      • パッケージ・インストール:/etc/dse/tomcat/conf
      • tarボール・インストール:installation_location/resources/tomcat/conf
    • アップグレードの前にスキーマを調整してください。DSE 5.1.4以降では、フィールドにインデックスが付いていなくても、スキーマ内のすべてのフィールド定義が検証され、DSE Searchと互換性があり、docValuesが適用されるか、コピー・フィールド・ソースに使用される必要があります。
    • 自動リソース生成のデフォルトの動作には、すべてのカラムが含まれます。パフォーマンスを改善するには、フィールドがデータベースからインデックス・パスに読み込まれないように対策を講じます。スキーマ内の未使用のフィールドを削除するかコメント・アウトします。
    • ユニーク・キー要素はすべてSolrスキーマでインデックスを付ける必要があります。ユニーク・キー要素を確認するには、schema.xmlですべてのユニーク・キー・フィールドがindexed=trueになっていることを確認します。

    • スキーマを変更した場合は、全インデックスを再作成してください。
  7. 構成 ファイルを、コマンドを通常実行するディレクトリーにないフォルダーにバックアップします。

    構成ファイルは、新しいバージョンのインストール中にデフォルト値で上書きされます。

    OpsCenter 6.5 Lifecycle Manager (LCM)を使用して、データ・センターまたはノードで、構成プロファイルの複製およびアップグレード・ジョブの実行ができます。アップグレード・ジョブは、DSE 5.0.x以降のDSEリリース・シリーズ内のアップグレードについてサポートされています。

  8. nodetool repairを実行して、各レプリカ上のデータと他のノード上のデータの整合性を確保します。

アップグレード手順

DataStax Enterpriseのアップグレード・プロセスは、ダウンタイムの最小化(ゼロ・ダウンタイムが理想)を実現します。プロセス中、他のノードがオンラインで稼働し続けている状態でノードを1つずつアップグレードして再起動します。若干の例外はありますが、クラスター内のすべてのノードがアップグレードされるまで、クラスターはDataStax Enterpriseの以前のバージョンであるかのように機能し続けます。

ヒント: DataStaxインストーラーは、多数のアップグレード・タスクを自動的に実行します。
  1. OpsCenter Repair Serviceが構成されている場合は、Repair Serviceをオフにします。
  2. アップグレードの順序は重要です。ノードは以下の順序でアップグレードします。
    • 複数データ・センター・クラスターでは、1つのデータ・センター内のすべてのノードをアップグレードしてから、別のデータ・センターをアップグレードします。
    • データ・センター内のシード・ノードを最初にアップグレードします。
    • ノードは以下の順序でアップグレードします。
      1. DSE Analyticsデータ・センター
      2. トランザクション/DSE Graphデータ・センター
      3. DSE Searchデータ・センター
  3. 次のようにnodetool drainを実行し、古いインストールのコミット・ログをフラッシュします。
    nodetool -h hostname drain 

    この手順により、アップグレード後のノードの起動時に時間が節約されるほか、DSE Searchノードでデータに再度インデックス付けする手間を省くことができます。

  4. ノードを停止します
  5. 適切な方法を使用して新しい製品バージョンをインストールします。
  6. 新しい製品バージョンを構成するには:
    1. バックアップ 構成 ファイルを新しい構成ファイルと比較します。
    2. 該当する変更を新しいバージョンにマージします。
  7. ノードを起動します
  8. アップグレード後のデータ・センター名がキースペース・スキーマ定義内のデータ・センター名と一致することを確認します。
    nodetool status
  9. 警告、エラー、および例外がないか、ログを確認します。

    多くの場合、警告、エラー、および例外は、アップグレードしたノードの起動時にログに表示されます。これらのログ・エントリーの一部は、固有のアップグレード関連の手順を実行するときに役立ちます。予想しなかった警告、エラー、または例外が表示された場合は、DataStaxサポートまでお問い合わせください。

  10. 2で説明しているように、推奨されるアップグレード順序に従って、クラスター内の各ノードでのアップグレードを繰り返します。

    各ノードでのアップグレードおよび再起動は、ローリング再起動と呼ばれます。

  11. 各ノードに新しいバージョンがインストールされたら、各ノードのSSTableをアップグレードすることをお勧めします。

    SSTableのアップグレードは、最適なパフォーマンス実現のために推奨されますが、パッチ・リリースでは必須ではありません。

    nodetool upgradesstables

    SSTableが既に現在のバージョンになっている場合、このコマンドは即座に終了し、アクションは発生しません。

    同時にアップグレードするSSTableの数を設定するには、--jobsオプションを使用します。デフォルト設定は2です。この設定にすると、クラスターへの影響を最小限に抑えられます。利用可能なすべてのコンパクション・スレッドを使用するには、0に設定します。高速化の方法など、nodetool upgradesstablesの詳細については、DataStaxサポートのナレッジ・ベース記事「Nodetool upgradesstables FAQ」を参照してください。

  12. DSE 5.1.6以降でのDSE Search:大きな暗号化インデックスを持つノードでの起動が遅い問題は解決されています。ただし、パフォーマンスの向上を実現するためにはアクションが必要です。お使いのクラスターの各ノードで、すべての暗号化検索インデックスを完全に再作成する必要があります。アップグレードが完了したら、ローリング方式でdeleteAll=trueを使用してインデックスを再作成するための時間を十分に取ってください。例を次に示します。
    dsetool reload_core keyspace_name.table_name distributed=false reindex=true deleteAll=true 
  13. DSE Searchのインデックス作成時のブーストのサポートは、DSE 5.1.1以降はなくなります。代わりにクエリー時のブーストを使用してください。バッキングCQLテーブルに_docBoostカラムがある場合は、それらを削除します。

    _docBoostカラムが存在していたThriftテーブルは許容されますが、_docBoostは無視されます。Thriftテーブルはこのカラムを削除できません。

  14. この手順は、DSE 5.1.0~5.1.2から5.1.3以降のDSE 5.1.xパッチ・リリースへのアップグレードのみに適用します。
    インクリメンタル・リペアの実行を続けるには、nodetool repair -incを使用します。
    重要: インクリメンタル・リペアから移行してインクリメンタル以外のフル(-full)リペアまたはパーティション(-pr)リペアを有効にするには、アップグレード後に最初のリペアを実行する前に、nodetool mark_unrepairedを使用してすべてのノードですべてのSSTableを未リペアとして設定する必要があります。
  15. OpsCenter Repair Serviceを使用する場合は、Repair Serviceをオンにします。