Clusterにおけるレプリケーション環境構築の具体例について解説します。Cluster」を利用するためのチュートリアルとなるように、その特徴と基本的なアーキテクチャからインストール方法、基本的な操作などをコマンド付きで解説していきます。Clusterにおけるレプリケーション環境構築の具体例について解説します。記事中のコマンド例は、第2回でインストールした環境に第5回で紹介したサンプルデータベース(worldデータベース)を作成した状態を前提としています(追加設定としてmysqlユーザーの環境変数"PATH"に"/home/mysql/mysqlc/bin"も追加した状態を前提)。レプリケーション環境構築の流れレプリケーション環境の構築は、以下の手順で行います。Cluster固有の手順です。Cluster用の手順で実施する必要があります。SLAVEを実行)マスターとスレーブを新規でセットアップした直後にレプリケーションを構成する場合は、マスターにまだデータが入っておらず、バイナリログも記録されていないため、上記手順の4~7を省略できます。今回はndb_apply_status、ndb_binlog_indexの確認方法を解説するため、マスターにデータが入っている状態からレプリケーション環境を構築していきます。Cluster環境を構築してレプリケーションを構成します。Cluster環境を構築してスレーブとします。Cluster環境それぞれの環境の配置ディレクトリ、設定ファイル名、ポート番号などを表1に示します。Clusterに自動採番で割り当てられるため、マスターとスレーブで重複する)。Clusterをセットアップします。Clusterをセットアップしてください。以下のパラメータはそれぞれの環境に応じて変更する必要があります。※[ndb_mgmd]セクションに存在(config2.iniに追記)my.cnfndb-connectstringserver_iddatadirportsocket参考情報として、スレーブのconfig.iniおよびスレーブのmy.cnf(SQLノード1用)をそれぞれリスト1、2に示します。マスター用のconfig.iniではポート番号を明示的に指定せずにデフォルトのポート番号(1186)を使用していましたが、スレーブ用のconfig.iniでは重複を避けるため明示的にポート番号を指定する必要があります。そのため、リスト1では[ndb_mgmd]セクションにPortNumberの設定を追記しています。マスター/スレーブにレプリケーション用の設定を行うレプリケーション用のバイナリログを出力するため、マスター/スレーブのSQLノードにリスト3を設定します(my1.cnf~my4.cnfにそれぞれ追記)。第7回で解説したように、混乱を避けるためにbinlog_format=ROWも明示的に設定しています。マスター上にレプリケーション用のユーザーを作成するスレーブがマスターへログインするためのレプリケーション用ユーザーを作成します。マスターのSQLノードへ接続し、リスト4のSQLを実行します。この例ではレプリケーション用のユーザー名を’repl’、パスワードを’repl’としていますが、任意で変更可能です。BACKUPコマンドを実行し、オンラインバックアップを取得します。オンラインバックアップ取得方法の詳細は、第5回を参照してください。スレーブへデータをリストアする手順4で取得したバックアップをスレーブへリストアします。データのリストアはndb_restoreコマンドで行いますが、この方法ではSQLノードが保持するスキーマ(データベース)の情報はリストアされません。そのため、事前にスレーブのSQLノードに接続してリスト5のSQLを実行し、マスターに存在していたworldデータベースを作成しておきます。world;その後、スレーブでndb_restoreコマンドを実行してデータをリストアします。スレーブで実行するため-cオプションの指定はリスト6のように「localhost:1187」になることに注意してください。ndb_restoreコマンドの使用方法の詳細は第5回を参照してください。BACKUP実行後の出力からも確認可能。completed」)。スレーブのndb_apply_statusテーブルからスレーブに反映済みのEpochを確認するスレーブのSQLノードに接続し、リスト7の手順でndb_apply_statusからスレーブに反映済みのEpochを確認します。リスト7の例では、反映済みのEpochが8834747727871になっています。マスターのndb_binlog_indexテーブルからマスターのバイナリログ情報を確認するマスターのndb_binlog_indexテーブルから、先ほどスレーブで確認したEpoch以降のバイナリログファイル名/ポジションを確認します。手順4のオンラインバックアップ取得以降にマスターでトランザクションが実行されていないと、対応するバイナリログファイル名/ポジションが確認できないため、リスト8では先にマスターでトランザクションを実行してからndb_binlog_indexテーブルを検索しています(トランザクションが実行されていない場合は、オンラインバックアップ取得以降のEpochの情報がndb_binlog_indexテーブルに追記されていないため、リスト8のSQLで対応するバイナリログファイル名/ポジションが特定できない)。TOコマンドを実行)スレーブのSQLノードに接続して、先ほど確認したマスターのSQLノードへの接続方法、バイナリログのファイル名、バイナリログポジションを指定してレプリケーションの設定を行います。リスト9では、マスターのSQLノード1のバイナリログファイルbinlog.000007、バイナリログファイルポジション120を指定してコマンドを実行しています(手順7で確認したバイナリログファイル名、ポジションを指定)。SLAVEを実行し、レプリケーションを開始します。SLAVE;レプリケーションの稼働確認レプリケーション環境が構築できたら、マスターでデータを更新し、更新内容がスレーブに伝搬されることを確認してください。リスト11では、マスターのworld.Cityテーブルにデータを追加し、そのデータがスレーブでも検索できることを確認しています。Clusterにおけるレプリケーション環境構築の具体例について解説しました。Clusterのチューニングの基礎について解説する予定です。※本稿において示されている見解は、私自身の見解であって、私の所属するオラクルの見解を必ずしも反映したものではありません。日本オラクル株式会社MySQLのセールスコンサルタント。元々はOracleデータベースのコンサルティング、サポート等に従事していたが、オープンソースとフリーソフトウェア(自由なソフトウェア)の世界に興味を持ち、MySQLの仕事を始める。趣味は旅行と美味しいものを食べること。Clusterにおけるチューニングの基礎について解説します。Clusterにおけるレプリケーション環境構築の具体例について解説します。Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。ITがお届けするポッドキャストです。