MySQL Cluster に関する FAQ

A: こちらを御覧ください http://www-jp.mysql.com/customers/cluster/。

A: 現在のバージョンは MySQL Cluster 7.2 です。MySQL 5.5 は、MySQL Cluster と統合およびバンドルされます。

A: 必要ありません。MySQL Cluster は、一般的なハードウェア上で実行するように設計されています。SCI ネットワーク相互接続などの特別なハードウェアを使用することで、さらに高いレベルのパフォーマンスを実現できます。

A:

A: 次のいずれかに該当する場合、MySQL Cluster が最適な選択肢となる可能性があります。

• データベースの障害が、ビジネスに多大な影響を与えるアプリケーションのダウンタイムを起こす。
• 現在のフェイルオーバー時間に満足していない。
• アプリケーションのデータベースで、自動フェイルオーバおよびリカバリによる「ファイブナイン」（99.999%）の可用性を提供する冗長性を組み込む必要がある。
• 現在のデータベースの問題が、書き込み処理にある。マスター/スレーブ型スケールアウト、および/または、アプリケーションのパーティショニングの代替ソリューションを検討している。
• アプリケーションがミリ秒単位の遅延でも影響を受けやすい。
• アプリケーション/サービスが予測可能な応答時間を提供する必要がある。
• SQLだけでなく、データへ直接アクセスする多様なアプリケーションを稼働している(Java および OpenJPA アプリケーション、OpenLDAP、Web サービスおよびC++ アプリケーション）。
• ハードウェア・リソースを効率的に利用する、アクティブ/アクティブ・クラスタリング・アーキテクチャを利用したいと思っている。
• アプリケーションが、主にプライマリキーのルックアップおよび「単純」なテーブル結合で構成されている。

MySQL Cluster 評価ガイド も参照してください。 MySQL Clusterの詳細については、MySQL Cluster関連情報も御覧ください。

A: Ideal applications include:

• 大容量 OLTP
• リアルタイム分析
• eコマース および不正検出機能を備えた金融取引
• モバイルおよびマイクロペイメント
• セッション管理およびキャッシング
• フィード・ストリーミング、解析およびレコメンデーション
• コンテンツ管理および配信
• 大規模マルチレイヤ・オンライン・ゲーム
• コミュニケーションおよびプレゼンス・サービス
• サブスクライバ / ユーザー・プロファイル管理およびエンタイトルメント（権限付与）

全てのMySQL Cluster ユーザー導入事例およびアプリケーションを参照ください。

A:

• 可用性
  • 99.999% (年間5分以内のダウンタイム)
• パフォーマンス
  • 応答時間: 5ミリ秒未満 (同期レプリケーションおよびSQLアクセス)。より高速なアクセスが、NoSQLアクセス・メソッドで達成可能。
  • デュアルソケットのインテルサーバー/24GB RAM上で1秒間に250,000以上のUPDATEを複製するスループット。 8台のインテル・サーバーで2.5百万UPDATE/秒。
    ベンチマークの詳細はこちら。
• フェイルオーバー
  • 1 秒以内のフェイルオーバーにより、中断せずに継続的にサービスを提供可能
• スケーラビリティ
  • 動的なスケールアウト、スケールアップ、スケールアウト
  • コスト効率的なスケールアウト:
    • クラスタあたりのデータ・ノードを追加（8、10、12、...48）
    • CPU をさらに追加（4、8 など）
    • データ・ノードあたりのメモリを増設（16GB、32GB など）

A: 評価目的では、全てのノードを1つのホストで実行できます。完全な冗長性および耐障害性を構築するには、最低6台のフ物理ホストが必要です。

• 2 x データ・ノード
• 2 x SQL/NoSQL アプリケーション・ノード
• 2 x 管理ノード

多くのユーザーが管理およびアプリケーション・ノードを同じ場所に配置し、ノードの数を4つに減らしています。

A: はい、ご使用のネットワークがこちらで説明されている特性を満たしている限り可能です。

MySQL Clusterは、これまで遠隔地レプリケーションを提供し、, クラスタをリモートのデータセンターに分散してデータをユーザーの近くへ移動することで地理的レイテンシの影響を低減し、またこれによりディザスタ・リカバリ機能も提供しました。

遠隔地レプリケーションは非同期でアクティブ/アクティブまたはアクティブ/パッシブ構成で実装可能です。

遠隔地レプリケーションは、データセンター間の運用モデルとしての推奨オプションです。

A: アプリケーションは、MySQL Connector を使用して開発できます。MySQL Cluster は、さらに、Memcached、C++、Java、OpenJPA 、LDAP　および HTTP/RESTなどを介してネイティブNoSQL接続を提供します。

A:ありません。これらのインタフェースは同じです。

A: はい。MySQL Cluster は、通常、ISV やネットワーク機器プロバイダ（NEP）により組み込みデータベースとして使用されます。顧客一覧については、http://www-jp.mysql.com/customers/cluster/ を参照してください。

A: 遠隔地レプリケーションにより、地理的に離れたクラスタ間で非同期レプリケーションを行うことができます。これは、通常、ディザスタリカバリに使用されます。

A: はい。MySQL Cluster では、単方向および双方向のレプリケーションがサポートされています。双方向遠隔地レプリケーションを使用する場合、トランザクション競合の検出および解決機能が提供されます。

A: MySQL Cluster 設定では、通常全てのデータの少なくとも 2 つのコピーが異なるホストに保持されます。総合的なシステム障害に対応するため、トランザクション・ログおよびチェック・ポイント・ファイルがディスクに保存されます。また、保存が行われる頻度は設定可能です。さらに、データをインデックスなしでディスクに保存することもできます。

A: MySQL Cluster には、ディスクレス・オプション、およびログなしオプションがあります。

ディスクレス・オプションでは、次の制限事項があります。

1. ディスクにデータが保存されない
2. 完全な Cluster 障害が発生した場合データが損失する
3. バックアップがない

ログなしオプションの場合でも、Cluster はログファイルを作成しますが、データのチェックポイントはディスクに保存されません。

A: いいえ。 MySQL Cluster Manager は 商用版のMySQL Cluster Carrier Grade Edition(CGE) データベースに含まれるコンポーネントです。MySQL Cluster CGE の購入については、MySQL の営業担当までお問い合わせください。

[Oracle Direct]
0120-155-096
※音声案内に従って2番を選択してください。
【受付時間】
平日 9:00-12:00/13:00-18:00
(祝日及び年末年始休業日を除きます)
mysql-sales_jp_grp@oracle.com

A: MySQL Cluster Manager は、基本的な管理タスクを自動化するソフトウェアで、MySQL Cluster CGE データベースの作成と管理を簡略化します。

A: MySQL Cluster Managerによって、データベース管理者 (DBA) とシステム・アドミニストレータの生産性が上がり、戦略的なIT構想に注力でき、ユーザーの変化する要求により迅速に対応することができます。さらに、これまで手動による構成エラーを原因として発生していたデータベースのダウンタイムが大幅に削減されます。

A: 例として、以前は46の手動のコマンド¹ とDBAによる2.5時間の作業²が必要だった管理処理の一つ、MySQL Clusterデータベースのローリング再起動が、たった1つのコマンドで実行可能で、MySQL Cluster Managerで完全に自動化されています。これにより以下が削減されます。

• 管理の複雑性と負荷
• 構成の自動化と管理プロセスの変更によるダウンタイムのリスク
• 管理コマンドのカスタム・スクリプト作成または独自の管理ツールの作成とメンテナンス

A: 管理者は、1つのコマンドで、クラスタ全体の作成と削除、停止と再起動を行うことができます。管理者は、各ノードを１つずつ手動で再起動する必要がなく、自動化のためのスクリプトを作成する必要もありません。

MySQL Cluster Manager は、実行しているクラスタのアップグレード、ダウングレードのオンライン管理作業を自動化し、データベースにアクセスするアプリケーションまたはクライアントに影響を及ぼしません。管理者は構成ファイルを編集してその他のすべてのクラスタに分配する、またはローリング・スタートする必要がありません。MySQL Cluster Manager がこれらすべてのタスクを処理し、ベストプラクティスを実施し、オンライン作業を大幅に簡略化、高速化し、エラーも少なくなります。

A: 両方できます。 MySQL Cluster Manager は、クラスタ全体を、1つの実体として管理することができます。クラスタ内の個々のプロセスの細かい管理を行うこともできます。

A: MySQL Cluster Manager は、クラスタ内の各ノードを自動的にポーリングすることによってオペレーティング・システムとプロセスレベルの両方で、クラスタの状態を監視することができます。プロセスまたはサーバー・ホストが アクティブか、停止しているか、ハングアップしているかを検出し、迅速な問題検出、ソリューションそしてリカバリへと導きます。

A: MySQL Cluster Manager は、これまで管理者による手動で行われてきた管理機能を統合して拡張しました。上の例で示したように、46 の手動によるコマンド・プロセスが自動化され１つのコマンドで実行できます。

カスタム管理システムを作成することは、手動で作成、テスト、維持することによって時間がかかる、コストが高い、エラーを発生するなどのデメリットがあります。多くのメンテナンス作業において、MySQL Cluster Managerはこれらのタイプの作業の必要性を削除してくれます。

自動化によって、コスト、リスク、負荷を軽減し、クラス管理を簡易化します。

A: はい。MySQL Cluster 自体、手動による操作を必要とせずに、自動的にデータノートを再起動して復旧する機能を備えています。 MySQL Cluster Manager は、SQLと管理ノードを監視して復旧することによって、この機能を拡張します。これによって、より完璧な自己復旧機能をサポートし、完全に稼働状態とアプリケーションに対するキャパシティを復旧することができます。

A: はい。ネイティブ NDB API を使用している場合を除いて(C++, Cluster Connector for Java, OpenLDAP, などのダイレクトインタフェースを使用してノードにアクセスしている場合)すべてできます。データ・ノード、管理ノード、SQLノード(MySQL サーバー・ノード）の管理、監視、リカバリを行うことができます。

A: いいえ。高可用稼働を保証するために、MySQL Cluster Manager は実際のデータベース・プロセスからは切り離されています。そのため、管理エージェントが停止またはアップグレードされた場合、稼働しているデータベースには影響がありません。MySQL Cluster Manager は、いずれかのエージェントまたは関連するホストが利用不可の状態に場合でも、稼働を続けているノードについて継続して作業を行います。

A: MySQL Cluster Manager はエージェントのセットとして実装されています。1つのエージェントが、 管理される MySQL Cluster ノード(プロセス)を含む各物理ホストで実行します。アドミニストレータが通常のmysql クライアントのいずれかのエージェントに接続し、エージェントがお互いに通信し共同作業し、Clusterを構成するノード全体について動作します。

A: MySQL Clusterの運用に MySQL Cluster Manager を使用する場合、管理者は構成ファイル(例えばconfig.ini や my.cnfなど) の編集をしません。代わりに、これらのファイルは、エージェントによって生成されメンテナンスされます。これらのファイルが手動で編集されると、それらの変更はエージェント内に保持されている構成情報によって上書きされます。

全ての MySQL Cluster の運用を構成しているプロセスは、MySQL Cluster Manager によって起動、再起動、停止が行われます。これにはデータ・ノード、管理ノード、MySQL サーバー・ノードが含まれます。

同様に、MySQL Cluster Managerを使用する場合、管理者は、ndb_mgm コマンドを使用して管理アクションを行ってはいけません（管理ノードに直接接続するため、エージェントにその操作が行われたことが認識できません）。

A: MySQL Cluster Manager を導入しても、管理ノードの必要性はなくなりません。特に以下のような重要な役割があります。

• データ・ノードが開始/再起動すると管理ノードに接続し、それらの構成データを取得します(管理ノードはエージェントによって作成された構成ファイルからそのデータを取得します）。
• MySQL Cluster Manager を介してデータ・ノードを停止または再起動すると、ステートの変更は管理ノードによって行われます。
• 管理ノードは引き続きアービトレータとして動作できます (split-brain を避けるため)。この理由で、それらのプロセスを、データ・ノードとは別のホスト上で実行することは重要です。
• レポート情報には、MySQL Cluster Manager で得られず、 依然として ndb_mgm ツールによって取得できるものがあります(例：メモリー使用状況）。

A: エージェント自体を監視するプロセスは存在しません。エージェントの可用性を高めるために、管理者が、例えばetc/init.d内にスクリプトを作成して、プロセス・モニタを使用してエージェントの障害を検出して、自動的に再起動するという選択肢があります。

A: はい。管理エージェントが再起動する際、自動的に実行している他のエージェントと同期し、クラスタ全体の構成の統一を保ちます。管理者の作業は必要ありません。

A: はい。すべての MySQL Cluster 構成情報とプロセス識別子は、システム障害またはMySQL Cluster Managerの再起動においてもディスクに残り変化しません。

A: MySQL Cluster Manager は、確実に構成リクエストを伝えるために、各管理エージェント間の非同期通信をサポートしています。そのため、クラスタ内の全てのノードで構成が統一されます。

いずれの変更も、全てのノードが再構成リクエストを受け取ったことを確認してから確定されます。１つまたは複数のノードがリクエストの受付に失敗すると、クライアントにエラーがレポートされます。再構成リクエストの通信と同期を自動化することによって、構成ファイルを手動で分配することを起因とするエラーが発生する可能性がなくなります。

A: サポートプラットフォーム・ページを御覧下さい: サポートプラットフォーム。

A: MySQL Cluster 6.3 以上です。

A: こちらのホワイトペーパーをご覧ください。