指定されたデータ・センターをデータ・ソースとして使用してクラスターへデータ・センターを追加する
指定されたデータ・センターをデータ・ソースとして使用してデータ・センターを既存のクラスターへ追加します。
指定されたデータ・センターをデータ・ソースとして使用してデータ・センターを既存のクラスターへ追加するには、次の手順を完了します。この手順では、新しいデータ・センターであるDC4が、既存のデータ・センターDC1、DC2、およびDC3がある既存のクラスターへ追加されます。
cassandra-rackdc.properties
cassandra-rackdc.propertiesファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/cassandra-rackdc.properties |
tarボール・インストール | installation_location/resources/cassandra/conf/cassandra-rackdc.properties |
cassandra.yaml
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/cassandra.yaml |
tarボール・インストール | installation_location/resources/cassandra/conf/cassandra.yaml |
dse.yaml
dse.yamlファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/dse.yaml |
tarボール・インストール | installation_location/resources/dse/conf/dse.yaml |
system.log
system.logファイルの場所は:- /var/log/cassandra/system.log
cassandra-topology.properties
cassandra-topology.propertiesファイルの場所は、インストールのタイプによって異なります。パッケージ・インストール | /etc/dse/cassandra/cassandra-topology.properties |
tarボール・インストール | installation_location/resources/cassandra/conf/cassandra-topology.properties |
始める前に
重要: 「DataStax Enterpriseクラスターの初期化」に記載する前提条件タスクを完了して環境を準備します。
手順
-
既存のデータ・センターで、SimpleStrategyレプリケーション・ストラテジが使用されている場合は、これをNetworkTopologyStrategyレプリケーション・ストラテジに変更します。
- OpsCenter Repair Service(リペア・サービス)を停止します(クラスターで実行されている場合)。「Repair Service(リペア・サービス)をオフにする」を参照してください。
-
新しいデータ・センターの各ノードにDSEをインストールします(「DSEのインストール」を参照)。サービスを開始したり、ノードを再起動しないでください。
重要: クラスターのすべてのノードに同じバージョンのDSEを使用します。
-
クラスター内の他のノードの構成に従って、新しい各ノードでcassandra.yaml のプロパティを構成します。
-
cassandra-rackdc.properties(GossipingPropertyFileSnitch)またはcassandra-topology.properties(PropertyFileSnitch)ファイルで、命名規則を使用してデータ・センターとラックの名前を各ノードのIPアドレスに割り当て、不明なノードにはデフォルトのデータ・センター名とラック名を割り当てます。
注: 移行情報:ファイルが存在する場合、GossipingPropertyFileSnitchは常に、cassandra-topology.propertiesを読み込みます。新しいデータ・センター、またはPropertyFileSnitchから移行したデータ・センターの各ノードから、ファイルを削除します。
# Transactional Node IP=Datacenter:Rack 110.82.155.0=DC_Transactional:RAC1 110.82.155.1=DC_Transactional:RAC1 110.54.125.1=DC_Transactional:RAC2 110.54.125.2=DC_Analytics:RAC1 110.54.155.2=DC_Analytics:RAC2 110.82.155.3=DC_Analytics:RAC1 110.54.125.3=DC_Search:RAC1 110.82.155.4=DC_Search:RAC2 # default for unknown nodes default=DC1:RAC1
注: 構成ファイルを変更したら、ノードを再起動して変更を有効にする必要があります。 -
既存のデータ・センターで以下の変化を行います。
-
既存のデータ・センターのノードで、新しいデータ・センターのシード・ノードを含めるように、
-seeds
プロパティ(cassandra.yaml 内で指定)を更新します。 - 新しいデータ・センター定義を、クラスターで使用されているタイプのスニッチのcassandra.yaml プロパティ・ファイルに追加します。スニッチを変更する場合は、「スニッチの切り替え」を参照してください。
-
既存のデータ・センターのノードで、新しいデータ・センターのシード・ノードを含めるように、
-
すべてのノードにDataStax Enterpriseをインストールして構成したら、シード・ノードを1つずつ起動した後で、残りのノードを起動します。
- パッケージ・インストール: DataStax Enterpriseをサービスとして起動
- tarボール・インストール: DataStax Enterpriseをスタンドアローン・プロセスとして起動
- 必要に応じて、新しいデータ・センターの各ノードにDataStaxエージェントをインストールして構成します。DataStaxエージェント6.7のインストール
-
nodetool status
を実行して、新しいデータ・センターが稼働していることを確認します。nodetool status
Datacenter: DC1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Owns Host ID Token Rack UN 10.200.175.11 474.23 KiB ? 7297d21e-a04e-4bb1-91d9-8149b03fb60a -9223372036854775808 rack1 Datacenter: DC2 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Owns Host ID Token Rack UN 10.200.175.113 518.36 KiB ? 2ff7d46c-f084-477e-aa53-0f4791c71dbc -9223372036854775798 rack1 Datacenter: DC3 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Owns Host ID Token Rack UN 10.200.175.111 961.56 KiB ? ac43e602-ef09-4d0d-a455-3311f444198c -9223372036854775788 rack1 Datacenter: DC4 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Owns Host ID Token Rack UN 10.200.175.114 361.56 KiB ? ac43e602-ef09-4d0d-a455-3322f444198c -9223372036854775688 rack1
-
クラスターですべてのノードが実行中になり、クライアント・アプリケーションがデータ・センターで認識されたら、cqlshを使用してキースペースを変更し、ターゲット・レプリケーションを新しいデータ・センターに追加します。
ALTER KEYSPACE keyspace_name WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'ExistingDC1' : 3, 'NewDC2' : 2};
警告: DSE SearchやDSE Analyticsなどのクライアント・アプリケーションが適切に構成されていない場合、オンラインになる前に新しいデータ・センターに接続する可能性があります。構成が適切でない場合、接続の例外、タイムアウト、データの不整合の原因となります。 -
新しいデータ・センターの各ノードに対し、ソース・データ・センターの対応するデータ・センター/ラックを指定してnodetool rebuildを実行します。
nodetool rebuild -dc source_datacenter_name:source_datacenter_rack_name
次のコマンドは、既存のデータ・センターDC1のデータを、各DC2ノード上の新しいデータ・センターDC2にレプリケートします。ラック仕様は、DC1のラック仕様に対応します。DC2:RACK1ノードで実行するコマンド:nodetool rebuild -dc DC1:RACK1
DC2:RACK2ノードで実行するコマンド:nodetool rebuild -dc DC1:RACK2
DC2:RACK3ノードで実行するコマンド:nodetool rebuild -dc DC1:RACK3
-
nodetool netstats
を使用し、各ノードのサイズを検証して新しいデータ・センターのリビルドの進捗状況を監視します。nodetool rebuild
コマンドは、DSEノードにJMX呼び出しを発行し、リビルドが終了するのを待ちます。その後、コマンドラインに戻ります。JMX呼び出しが起動されると、nodetool rebuildプロセスに関係なくサーバー上でリビルド・プロセスが継続されます(nodetoolが終了しても、リビルドの実行は継続します)。nodetool rebuildコマンド自体からは、特に重要な出力はありません。その代わり、nodetool netstats
を使用し、各ノードのデータ・サイズを調べてリビルドの進捗状況を監視してください。注:nodetool status
で表示されデータ負荷が更新されるのは、所定のソース・ノードがストリーミングを終了した後なので、ディスクについて報告されるバイト数と開きがあるように見えます(例:du)。ストリーミング・エラーが発生した場合、ERROR
メッセージがsystem.log に記録され、リビルドが停止します。一時的な障害が発生した場合は、nodetool rebuild
を再度実行できます。その際、既に正常にストリーミングされた範囲はスキップされます。 - ネットワーク・トラフィックを釣り合わせるため、ソース・データ・センターのストリーミング・スロットルを調整します。「nodetool setstreamthroughput」を参照してください。
-
すべてのリビルドが成功したことを、
finished rebuild
を検索して確認します。これは、新しいデータ・センターの各ノードの system.log に記録されています。注: まれに、2つのストリーミング・ノード間の通信がハングし、データがストリーミングされることなくリビルド操作が有効な状態になる場合があります。nodetool netstats
を使用してストリーミングの進捗状況を監視してください。ストリームに何の進捗も見られない場合は、nodetool rebuild
が実行されたノードを再起動し、当初使用したものと同じパラメーターを使用してnodetool rebuild
を再実行してください。 - 必要に応じ、新しいデータ・センターの各ノードでDataStax Agentを起動します。
- 必要に応じてOpsCenter Repair Service(リペア・サービス)を起動します。「Repair Service(リペア・サービス)をオンにする」を参照してください。