[Cassandra Wiki] Update of "LiveSchemaUpdates_JP" by yukim

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "LiveSchemaUpdates_JP" page has been changed by yukim.
http://wiki.apache.org/cassandra/LiveSchemaUpdates_JP?action=diff&rev1=14&rev2=15

--------------------------------------------------

  ## page was copied from LiveSchemaUpdates
- = Modifying Schema on a Live Cluster =
- This page discusses features available in 0.7 (only available as svn trunk, as of this writing).
+ = 稼働中のクラスタのスキーマを変更する =
+ このページではバージョン0.7で利用可能になる機能について議論します(現時点でsvn trunkでのみ利用可能です)。
  
- == Under the Hood ==
- A new system table called `definitions` keeps track of two things: keyspace definitions (`SCHEMA_CF`) and keyspace changes (`MIGRATIONS_CF`).  TimeUUIDs are used throughout to match migrations up with schema and vice-versa.
+ == スキーマアップデートの中身 ==
+ 新しく導入された`definitions`システムテーブルが2つのデータの追跡をします: キースペースの定義(`SCHEMA_CF`)とキースペースの変更(`MIGRATIONS_CF`)です。変更をスキーマとマッチさせるために全体的にTimeUUIDが利用されています。
  
- === Keyspace Definitions (SCHEMA_CF) ===
- The current set of keyspace definitions are stored in a single row, one keyspace per column with a TimeUUID as the row key (also serves as version identifier), keyspace name as column name, and definition serialization as the column value.  There exists a special row, keyed by `"Last Migration"` that contains a single column indicating the current schema version UUID.  This makes it easy to look up the version and then retrieve it.
+ === キースペースの定義 (SCHEMA_CF) ===
+ 現在のキースペース定義は、1行のデータとして格納されます。1つのキースペースがカラムに格納され、TimeUUIDを行のキーとして(それはバージョンを識別するのにも利用されます)、キースペースの名前がカラム名となり、定義をシリアライズしたものがカラムの値に入ります。`"Last Migration"`というキーをもつ特別な行があり、現在のスキーマのバージョンのUUIDを保持します。これは現在のバージョンを探しやすくするためです。
  
- === Migrations (MIGRATIONS_CF) ===
- `MIGRATIONS_CF` tracks the individual modifications (add, drop, rename) that are made to the schema.  It consists of a single row keyed by `"Migrations Key"` with one column per migration.  Each column has the migration version UUID as its name, with the serialized migration as its value.
+ === マイグレーション (MIGRATIONS_CF) ===
+ `MIGRATIONS_CF`はスキーマに対する個々の変更点(追加、削除、名前変更)を追跡します。 `"Migrations Key"`というキーを持つ単一行で構成され、1つの変更が一つのカラムに格納されます。 個々のカラムは変更のバージョンを管理するUUIDをカラム名に持ち、シリアライズされた変更データがカラム値として格納されます。
  
  {{attachment:migrations.gif}}
  
- == Operations ==
- === Client Operation ===
-  * Add column family or keyspace
-  * Drop column family or keyspace
-  * Rename column family or keyspace
+ == 操作 ==
+ === クライアントからの操作 ===
+  * カラムファミリもしくはキースペースを追加する
+  * カラムファミリもしくはキースペースを削除する
+  * カラムファミリもしくはキースペースの名前を変更する
  
- These are all executed via the [[API|Thrift API]].  It is expected that you have `ALL` access if you are using security.  For rename and drop operations the client will block until all associated files are renamed or deleted.
+ これらはすべて [[API|Thrift API]] を通して実行されます。セキュリティ機能を利用している場合は、`ALL`のアクセス権限を持っていることが前提となります。名前変更もしくは削除を行う場合、関連するすべてのファイルが名前変更もしくは削除されるまで、クライアントはブロックされます。
  
- === Server Migration Process ===
- Applying a migration consists of the following steps:
+ === サーバ側のマイグレーションプロセス ===
+ マイグレーションの適用は次のステップで実行されます:
  
-  1. Generate the migration, which includes a new version UUID.
-   a. `DROP`s only: snapshot the data that is going away.
-  1. Update `SCHEMA_CF` with a new schema row.
-  1. Update `MIGRATION_CF` by appending a migration column.
-  1. Update the `"Last Migration"` row in `SCHEMA_CF`.
-  1. Flush the definitions table.
-  1. Update runtime data structures (create directories, do deletions, etc.)
+  1. 新しいバージョンのUUIDを含むマイグレーションの生成。
+   a. `DROP`時のみ: 削除対象のデータのスナップショットを作成。
+  1. `SCHEMA_CF`に新しいスキーマの行を追加して更新。
+  1. `MIGRATION_CF`にマイグレーションカラムを追加。
+  1. `SCHEMA_CF`の`"Last Migration"`を更新。
+  1. 定義テーブルをフラッシュ。
+  1. 実行時のデータ構造を更新(ディレクトリの作成、削除の実行、など)。
  
- === Handling Failure ===
- A node can fail during any step of the update process.  Here is an examination of what will happen if a node fails after each part of the update process (see Server Migration Process above).
+ === 失敗時の挙動 ===
+ 更新のプロセスの中のどのステップにおいても、変更の失敗が発生する可能性があります。更新プロセスの中の個々のステップ後に障害が発生した場合、何が起こるのかを詳しく見ていきます(上記のServer Migration Processを参照してください)。
  
-  1. Nothing has been applied. Update fails outright.
-   a. Same. You will have an extra snapshot though.
-  1. Extra data exists in SCHEMA_CF but will be ignored because "Last Migration" was not updated.
-  1. Extra data exists in SCHEMA_CF and MIGRATION_CF but will be ignored because "Last Migration" was not updated.
-  1. '''Broken''': commit log will not be replayed until *after* schemas are loaded on restart.  This means that the "Last Migration" will be read, but will not be able to be loaded and applied.
-  1. Startup will happen normally.
-  1. Startup will happen normally.
+  1. 何も適用されない。更新はすぐに失敗する。
+   a. 同じ. ただしスナップショットが残る。
+  1. SCHEMA_CFに余分なデータが残るが、"Last Migration"の行が更新されないため無視される。
+  1. SCHEMA_CFとMIGRATION_CFに余分なデータが残るが、"Last Migration"の行が更新されないため無視される。
+  1. '''故障''': 再起動時にスキーマがロードされた *後* までコミットログは再生されません。つまり"Last Migration"は読み込まれますが、ロードして適用することができません。
+  1. 正常に起動する。
+  1. 正常に起動する。
  
- If a node crashes during a migration, chances are you will have to do some manual cleanup.  For example, if a node cashes after steps 4 or 5 of a `DROP` migration, you will need to manually delete the data files.  (Not deleting them does no harm unless you 'recreate' the same CF via `ADD` later on. Then you have an instant database.)
+ マイグレーション中にノード障害が発生した場合、手動でクリーンアップしないといけない場合があります。例えば、`DROP`時のステップ4もしくはステップ5の後にノード障害が発生した場合、手動でデータファイルを削除する必要があります(削除しなくても特に害をなしませんが、後に`ADD`を利用して同じCFを再作成した場合に問題が起こります。その場合すでにデータベースができあがってしまっています)。
  
- === Starting Up ===
- When a node starts up, it checks `SCHEMA_CF` to find out the latest schema version it has.  If it finds nothing (as would happen with a new cluster), it loads nothing and logs a warning.  Otherwise, it uses the uuid it just read in to load the correct row from `SCHEMA_CF`.  That row is deserialized into one or more keyspace definitions which are then loaded in a manner similar to the load-from-xml approach used in the past.
+ === 起動 ===
+ ノードの起動時、`SCHEMA_CF`をチェックして一番最新のスキーマのバージョンを探します。 何もみつからなければ (新規にクラスタを構築した場合)、何も読み込まれずに警告ログが出力されます。それ以外ではUUIDを利用して`SCHEMA_CF`から正しい行を読み込みます。その行は1つ以上のキースペース定義にデシリアライズされます。それらは以前使われていたload-from-xmlに似たアプローチでロードされます。
  
- At the same time, the node incorporates its schema version UUID into the gossip digests it sends to other nodes.  It may be the case that this node does not have the latest schema definitions (as a result of network partition, bootstrapping a new node, or any other reason you can think of).  When a version mismatch is detected the definition promulgation mechanism described next is invoked.
+ それと同時に、ノードは自身のスキーマのバージョンのUUIDを他のノードへ送るゴシップダイジェストへ含めます。このノードが最新のスキーマ定義情報を持たないケースがありえます(ネットワークパーティショニング、新しいノードのブートストラップなどの理由によって)。もしバージョンに不一致がある場合、次で説明する定義の伝搬メカニズムが実行されます。
  
- === Definition Promulgation ===
- Definition promulgation consists of two phases: ''announce'' and ''push''. ''announce'' is a way for node A to declare to node B "this is the schema version I have".  If the versions are equal, the message is ignored.  If A is newer, B responds with an ''announce'' to A (this functions as a request for updates).  If A is older, B responds with a ''push'' containing all the migrations from B that A doesn't have.
+ === 定義情報の伝播 ===
+ 定義情報の伝播は2つのフェーズから構成されます: ''アナウンス'' と ''プッシュ''です。 ''アナウンス''は、ノードAがノードBに対して”これが自分の持っているスキーマのバージョンだ”と宣言する方法です。もしバージョンが一致する場合、メッセージは無視されます。 もしAが新しい場合、Bは''アナウンス''をAに返します(これは更新リクエストのように機能します)。もしAが古い場合、BはAが持っていないBのマイグレーションデータのすべてとともに''プッシュ''を返します。
  
- When a schema update originates from the client (Thrift), gossip promulgation is bypassed and this ''announce-announce-push'' approach is used to push migrations to other nodes.
+ クライアント(Thrift)からスキーマ更新が行われた場合、ゴシップ伝播はバイパスされ、マイグレーションを他のノードに伝えるのにこの''アナウンス-アナウンス-プッシュ''アプローチが利用されます。
  
- === New Cluster (Fresh 0.7) ===
- For new clusters, things will work best if you start with one node and apply migrations using Thrift until you get the schema you want.  Then bring new nodes online and they will pull migrations from the first node (or each other in a large cluster).
+ === 新規のクラスタ(バージョン0.7で構成) ===
+ 新規クラスタの場合、1つのノードから始めて、Thriftを利用して必要なスキーマを定義していくことが、一番うまくいきます。その後新しいノードを起動すると、自動的に最初のノードから情報を取得します(または大きいクラスタでは相互に行います)。
  
- Alternatively, you could then shut down the first node and manually copy its `SCHEMA_CF` and `MIGRATIONS_CF` to each new node in the cluster.
+ もしくはこの時点で最初のノードを停止して、クラスタ内の他のノードに`SCHEMA_CF`と`MIGRATIONS_CF`を手動でコピーすることができます。
  
- The simplest method of applying these schema changes is with `bin/cassandra-cli`. You can either do this interactively, or place the commands in a file and apply them in batch mode (type `help` and `help <command>` to see the available commands). For example:
+ スキーマ変更の簡単な適用方法は、`bin/cassandra-cli`を利用することです。インタラクティブモードで実行することもできますし、コマンドを記述したファイルを用意してバッチモードで適用することもできます(`help`もしくは`help <command>`で利用可能なコマンドを見ることができます)。例えば:
  
  {{{
  $ cat schema.txt
- /* Create a new keyspace */
+ /* キースペースを作成 */
  create keyspace Keyspace1 with replication_factor = 3 and placement_strategy = 'org.apache.cassandra.locator.RackUnawareStrategy'
  
- /* Switch to the new keyspace */
+ /* 作成したキースペースへ移動 */
  use Keyspace1
  
- /* Create new column families */
+ /* カラムファミリを作成 */
  create column family Standard1 with column_type = 'Standard' and comparator = 'BytesType'
  create column family Standard2 with column_type = 'Standard' and comparator = 'UTF8Type' and rows_cached = 10000
  $ bin/cassandra-cli --host localhost --batch < schema.txt
  }}}
- === Existing Cluster (Upgrade from 0.6) ===
- To provide some backwards compatibility, we've provided a JMX method in the `StorageServiceMBean` that can be used to manually load schema definitions from storage-conf.xml.  This is a one-shot operation though, and will only work on a system that contains no existing migrations.  If you are upgrading a cluster, you will probably only have to do this for one node (a seed).  Gossip will take care of promulgating the changes to the rest of the nodes as they come online.
+ === 既存のクラスタ (0.6からのアップグレード) ===
+ 後方互換性を維持するため、storage-conf.xmlから手動でスキーマ定義をロードできるJMXのメソッドを`StorageServiceMBean`に提供します。これは一度限りの操作です。まだマイグレーション情報がないシステムでのみ動作します。クラスタをアップグレードする場合、シードとなっている1つのノードだけに適用すればよいはずです。他のノードには、それらが起動した際にゴシップを通じて変更が伝播されます。
  
- For those who dont know how to do it (like me):
+ (私のように)どのように行えばいいか分からない人へ:
  
  {{{
- ps aux | grep cassandra # get pid of cassandra
+ ps aux | grep cassandra # cassandraのpidを取得
  jconsole PID
  }}}
  MBeans -> org.apache.cassandra.db -> StorageService -> Operations -> loadSchemaFromYAML
  
- Lastly, there is a system tool that can poke the same JMX method without having to remember its location:
+ 最後に、上記のJMXの場所を覚えることなく同じことが実行できるシステムツールがあります。
  
  {{{
  bin/schematool HOST PORT import
  }}}
  
- === Concurrency ===
- It is entirely possible and expected that a node will receive migration pushes from multiple nodes.  Because of this, all migrations are applied on a single-threaded stage and versions are checked throughout to make sure that no migration is applied twice, and no migration is applied out of sync.
+ === 並列性 ===
+ あるノードが複数のノードからマイグレーション情報を受信することは十分考えられます。 このことから、すべての変更の摘要はシングルスレッドのステージで行われます。そして、全体を通してバージョンをチェックし、変更が2回適用され庭内かをチェックします。同期なしに変更は適用されません。
  
- Each migration knows the version UUID of the migration that immediately precedes it.  If a node is asked to apply a migration and its current version UUID does not match the last version UUID of the migration, the migration is discarded.
+ すべての変更は次に適用される変更のバージョンUUIDを知っています。もしノードにマイグレーションの適用が指示され、その現在のバージョンUUIDが最後のマイグレーションのバージョンUUIDをマッチしない場合、そのマイグレーションは破棄されます。
  
- One weakness of this model is that it is vulnerable if a new update starts before another update is promulgated to all live nodes--only one migration can be active within a cluster at any time.  One way to get around this is to choose one node and only initiate migrations through it.
+ このモデルの弱点の1つは、他の更新がすべてのライブノードに伝播してくる前に新しい更新が始まる場合に弱いことです--ただ一つのマイグレーションしかクラスタ内に存在できません。これを回避する一つの方法は、1つのノードを選び、そのノードからのみマイグレーションを生成させることです。