クラスターへのデータ・センターの追加

データ・センターを既存のクラスターに追加する手順。

1. クライアントが新しいデータ・センターに先に接続しないようにし、読み取りまたは書き込みの整合性レベルによって新しいデータ・センターに対してクエリーが実行されないようにするには、以下の手順を実行します。
   1. クライアントがDCAwareRoundRobinPolicyを使用するように構成されていることを確認します。
   2. クライアントが既存のデータ・センターを参照し、まったくデータが存在しない可能性がある新しいデータ・センターにアクセスを試行しないことを確認します。
   3. QUORUM整合性レベルを使用する場合は、LOCAL_QUORUMに変更します。
   4. ONE整合性レベルを使用する場合は、LOCAL_ONEに変更します。

   ドライバーのプログラミング手順を参照します。

   警告: DSE SearchやDSE Analyticsなどのクライアント・アプリケーションが適切に構成されていない場合、新しいデータベースの準備が整う前にこのデータベースに接続する可能性があります。その結果、接続例外、タイムアウト、または不整合データが生じる可能性があります。
2. キースペースを構成して、新しいデータ・センターを作成します。
   1. ALTER KEYSPACEを使用して、以下のキースペースにNetworkTopologyStrategyを使用します。
      • すべてのユーザー作成キースペース
      • システム：system_distributed、system_auth、system_traces
      • DataStax Enterprise定義：dse_perf、dse_security、dse_leases。
      • OpsCenter（インストールされている場合）

      nodetool rebuild（10）では、指定されたソース・データ・センターのキースペースのレプリカが必要なため、複数のデータ・センターのクラスターでこの手順が必要となります。

   2. すべての既存のデータ・センターがNetworkTolologyStrategyを使用していることを確認します。

      cqlshを使用してキースペースを作成または変更できます。

      ALTER KEYSPACE "sample_ks" WITH REPLICATION =
        { 'class' : 'NetworkTopologyStrategy', 'ExistingDC' : 3 };

3. 新しいデータ・センターで、新しい各ノードにDataStax Enterpriseをインストールします。サービスを開始したり、ノードを再起動しないでください。
   クラスターのすべてのノードに同じバージョンのDataStax Enterpriseがインストールされていることを確認してください。「DataStax Enterprise 5.1.xパッチ・リリースのインストール」を参照してください。
4. クラスター内の他のノードの構成に従って、新しい各ノードでcassandra.yamlを構成します。
   1. クラスター内の他のノードのcassandra.yamlファイルの設定に合わせるため、-seedsやendpoint_snitchなどのその他のcassandra.yamlプロパティを設定します。「ワークロードの種類別に複数のデータ・センターを初期化する」を参照してください。
      注: すべてのノードをシードにしないでください。「ノード間のコミュニケーション（ゴシップ）」を参照してください。
   2. ノード・アーキテクチャーを構成します（データ・センター内のすべてのノードはその型を使用します）：
      • 仮想ノード（vnode）割り当てアルゴリズムの設定：
        • num_tokensを8に設定します。
        • allocate_tokens_for_local_replication_factor を新しいデータ・センターのキースペースのターゲット・レプリケーション係数に設定します。キースペースRFが変化したら、設定を交互に指定し、すべてのレプリケーション係数を使用します。
        • initial_tokenをコメントアウトします。
        注: 詳細については、「仮想ノード（vnode）の構成」を参照してください。
      • 単一トークン・アーキテクチャーの設定：
        • ノードごとに初期トークンを生成して、その値をinitial_tokenプロパティに設定します。

          「単一トークン・アーキテクチャー・データ・センターを初期化する」および「単一トークンのノードの追加または置き換え」を参照してください。

        • num_tokensとallocate_tokens_for_local_replication_factorの両方をコメントアウトします。
5. 新しいノードごとに、クラスターで使用されるスニッチの種類について、新しいデータ・センターの定義をプロパティ・ファイルに追加します。
   注: DseSimpleSnitchは使用しないでください。DseSimpleSnitch（デフォルト）（デフォルト）は、単一データ・センターのデプロイにのみ使用されます。このスニッチは、データ・センターやラック情報を認識せず、単一のデータ・センターでのデプロイや、公開クラウドの単一ゾーンでのデプロイの場合にのみ使用できます。

   表 1. スニッチごとの構成ファイル

   スニッチ	構成ファイル
   GossipingPropertyFileSnitch	cassandra-rackdc.propertiesファイル
   Ec2Snitch
   Ec2MultiRegionSnitch
   GoogleCloudSnitch
   PropertyFileSnitch	cassandra-topology.propertiesファイル

6. 既存のデータ・センターの場合：
   1. いくつかのノードでは、cassandra.yamlファイルのシード・プロパティを更新して、新しいデータ・センターにシード・ノードを含め、これらのノードを再起動します（cassandra.yamlファイルの変更を有効にするには、再起動が必要です）。
   2. クラスターで使用されるスニッチの種類について、新しいデータ・センターの定義をプロパティ・ファイルに追加します（5）。スニッチを変更する場合は、「スニッチの切り替え」を参照してください。
7. ラックごとに1つのノードでDataStax Enterpriseを起動します。
8. すべてのノードが起動するまでラックからのDSEの起動をローテーションします。
9. クラスターですべてのノードが実行中になり、クライアント・アプリケーションがデータ・センターで認識されたら（1）、cqlshを使用してキースペースを変更します。

   ALTER KEYSPACE "sample_ks" WITH REPLICATION =
       {'class’: 'NetworkTopologyStrategy', 'ExistingDC':3, 'NewDC':3};

   警告: DSE SearchやDSE Analyticsなどのクライアント・アプリケーションが適切に構成されていない場合、新しいデータベースの準備が整う前にこのデータベースに接続する可能性があります。その結果、接続例外、タイムアウト、または不整合データが生じる可能性があります。
10. 新しいデータ・センターの各ノードでnodetool rebuildを実行します。

    nodetool rebuild -- datacenter_name

    注意: コマンドラインに既存のデータ・センターを指定しないと、新しいノードはあたかもリビルドが成功したかのように見えますが、データは含まれていません。

    この手順を実行しないと、新しいデータ・センターへ整合性レベルLOCAL_ONEまたはONEを指定して要求を発行した場合は、既存のデータ・センターが完全に同期していないと失敗する可能性があります。

    この手順によって、新しいノードがクラスター内の既存のデータ・センターを認識していることが確認されます。

    nodetool rebuildは、複数のノードで同時に実行できます。ノードごとにnodetool rebuildを実行すると、既存のクラスターに与える影響は減少します。クラスターが余分なI/Oとネットワーク負荷を処理可能な場合は、複数のノードで実行してください。