MySQLでレプリケーションを行う手順と気をつけるべき点を紹介

TOP
コラム
MySQLでレプリケーションを行う手

はじめに

データベースは「データを入れておく箱」というように説明されることがありますが、おもちゃ箱のように無造作に格納されているわけではありません。データベースは初めに、どういったデータをどのように分割し、管理していくかという項目を洗い出し、無駄を省いて整理してシステムの将来性までを見越した設計が行われます。そのため、必要な時に必要なデータを素早く効率的に取得できるようになります。この仕組みはショッピングサイトや予約サイト、ログインシステム、ゲーム、業務システムといった様々な場面で長年利用され続けています。

そんなデータベースには様々な種類があり、そのカテゴリをリレーショナル型、NoSQL型、ネットワーク型、階層型に分けて説明されることがあります。2022年現在、データベースというとこの4つのうちリレーショナル型のことを指すことがほとんどで、今回取り上げる「MySQL」もリレーショナル型のデータベースの一つです。他に有名なものではPostgreSQL、Oracle Database、Microsoft SQL Server、SQLite等があります。また、NoSQLも徐々に採用するシステムが増えています。

かつてはWeb上でクレジットカード等の個人情報を登録するのをなるべく避けたいという人も多くしましたが、様々なサービスがオンライン化されたり、セキュリティ技術が向上したことにより、アカウント登録やオンラインショッピング等で、個人情報を登録することが当たり前のようになりました。そのため流出を防ぐことはもちろんですが、データを損失するようなことになれば、同時に企業の利益にも大きな打撃を与えることになるため、あらかじめ対策をとっておく必要があります。今回は、データの損失を防ぐことが可能な機能「レプリケーション」について紹介していきます。なお、MySQLに焦点を当てた内容となるので、ご注意ください。

MySQLについて

MySQLがリレーショナル型であることを前述しましたが、リレーショナル型とは、Excel等の表計算ソフトで作成する表を想像していただくとわかりやすいでしょう。例えば、生徒ごとの各科目の点数が一目で確認できる表を作成するとなった場合、縦横それぞれに、科目名、生徒名を入力した上で点数を挿入していきますが、リレーショナル型もこれと同じ表の形式でデータを管理していきます。データベースではこの表のことを「テーブル」と言い、大規模なシステムであればある程、複数のテーブルを組み合わせたデータベースを管理していくことになります。

以上はリレーショナル型に関する説明ですが、MySQL自体についての説明もしておきます。MySQLは、小規模・大規模にかかわらずWebシステムを中心に幅広く利用されているRDBMS(リレーショナルデータベース管理システム)で、ブログやホームページを運用する際に良く利用されるCMS「WordPress」でもPHPというプログラミング言語と共に採用されている他、クラウドサービスでも採用されることが多い状況です。

オープンソースとなっているので誰でも自由にカスタマイズが可能で、有償版の商用もありますが、無償版であっても十分に利用できます。有償版のソフトウェアで発生しがちな煩わしいライセンス管理から解放され、ライセンス料等のコスト削減も実現できるという点は企業にとって大きなメリットです。無償版にも「GPL」というライセンスがありますが、GPLライセンスが適用されているプログラムは再配布が行えないという決まりがあり、再配布等のGPLライセンスでの利用に認められない利用をする場合は、有償での契約を結ぶこととなります。また、2022年時点でMySQLの管理はOracle社(2010年〜)となっていますが、有償版の場合はOracle社によるサポートが受けられます。特にベンチャー、スタートアップ系の企業で利用されることの多いデータベースです。

レプリケーションの概要と注意点

「レプリカ」に近い単語なのでピンとくる方もいるかもしれませんが、レプリケーションとは「複製」のことを表しており、言い換えるとデータベースをミラーリングすることを表しています。ミラーリングする元となるデータベースを「マスター」、ミラーリングしてできたデータベースを「スレーブ」と呼んで表されることが一般的ですが、プロジェクトや企業によっては異なる名称を使う場合もあるので、それぞれがどのような役割を持ったデータベースであるかということを覚えておきましょう。なお、マスターとスレーブという呼ばれ方に関してはデータベースに限らず、DNSサーバーでもプライマリDNS(元のDNS)、セカンダリDNS(プライマリの情報を同期したDNS)に対してそう呼ぶこともあるため、会話の流れや文脈からどちらの話をしているのか判断する必要があります。また、一つのマスターに対してスレーブを複数持つことは可能ですが、スレーブの元となるマスターを複数とすることはできません。

レプリケーションを行う目的は主に3つあります。一つ目は、負荷分散ができるという点です。例えば人気のWebサービスでアクセス数が多く、データベースのデータ参照が頻繁に発生するとどうしてもデータベースサーバーに負荷がかかります。そのためマスターと同期したスレーブ用のサーバーを別に構築して、参照先をその両方とすることで多くのアクセスがあってもサーバーにかかる負荷を分散させることができます。

二つ目はデータベースに影響があるシステム障害があったとしても、影響を受けていないデーターベースを参照先として切り替えることで、サービスを提供し続けることが可能となる点です。あるいは停止したとしても早急な復旧が可能となります。これを「サービスの可用性を高める」とも言います。もちろん可用性を高めるためのミラーリングは他のサーバーでも同様に行われることが多く、障害が復旧したらメインのサーバーに切り替え直します。

三つ目は、サーバーを稼働させたままコールドバックアップの取得が可能という点です。上記説明文は相反する内容が同時に含まれているため、多少サーバー知識を持っている場合、状況説明に一瞬混乱してしまう可能性があることを想定し、もう少し噛み砕いて解説します。

まず「コールドバックアップ」に含まれている「コールド」ですが、通常の英単語のようにITシステムでは「コールド/ホット」が対義語として使われることが良くあります。「コールドバックアップ」に対しての「ホットバックアップ」、「コールドスタンバイ」に対する「ホットスタンバイ」等です。コールドバックアップとは通常、サービス停止状態でのバックアップを表し、ホットバックアップはその逆です。コールドスタンバイは障害発生時に切り替えるサーバーの電源が入っていない状態を表し、ホットスタンバイはその逆となります。

これらの傾向からすると「サーバーを稼働させたまま」=「ホット」を連想するものの、それに続く言葉が真逆の「コールドバックアップが可能」となっているので混乱を招くわけです。ここでいうコールドバックアップは、コールドバックアップによってデータをバックアップするのと同じ状態でのバックアップが可能ということを表しています。

コールドバックアップはサービス停止状態でのバックアップなので、その間バックアップ元となるサーバーのデータは更新が発生しません。そのため、この方法でバックアップを取るとバックアップ先とのデータが一致した状態となり、これはコールドバックアップのメリットとなります。以上により、「サーバーを稼働させたままコールドバックアップの取得が可能」をさらに言い換えると、サーバーを稼働させたままであるにもかかわらず、コールドバックアップのメリットが受けられるということになります。マスターの稼働を継続して、スレーブを停止した状態でバックアップを取ることでこれが可能となります。

ここまでですでにお気づきの方もいるかもしれませんが、レプリケーションのデメリットも紹介しておきます。レプリケーションはマスターのミラーリングであるため、ほぼマスターと同様の容量が別に作成されます。単純計算で倍の容量が必要となるので、その分のコストが発生します。また、次に紹介する同期方法を読んでいただくとMySQLでは生じない問題であることがわかると思いますが、メインデータベースで問題が発生している場合にスレーブへ同じ内容が複製されてしまうという点も、データベースの種類によってはデメリットとなります。

MySQLにおけるレプリケーションの同期方法について

レプリケーションを実施する際にはマスターとスレーブのデータの同期を取る必要がありますが、その方法には「同期」「非同期」「準同期」の3種類があります。MySQLはそのうち非同期、順同期に対応しているデータベースですが、準同期を行う場合はバージョンが5.5以上で、さらに専用プラグインのインストールが必要です。「同期」ではリアルタイムの同期が行われるので、障害が発生した場合はスレーブに直前の情報まで保存されます。その一方で、データに問題が発生した場合も問題の部分まで即時スレーブに反映されてしまいます。「非同期」の場合は、あくまでスレーブからリクエストがあったタイミングでのみ同期が取られることとなるので、問題が生じた場合にはスレーブに反映させずに済む、マスターとスレーブを常時接続しておく必要がないというメリットがあります。非同期のデメリットとしては、障害が発生する直前の内容が一切スレーブに反映されないという点が挙げられます。「準同期」は、スレーブ側に変更点に関する情報のみ転送しておき、その後は非同期で反映させることが可能です。

レプリケーションの注意点

前述した通り、レプリケーションにおいてはシステムに適した同期方法を選択することが重要ですが、その他にも注意点があるため、今回は特に押さえておきたい3つに絞って紹介しておきます。一つ目はマスターのバイナリログの設定を無効にした場合、スレーブには反映されないという点です。マスター側の設定に「set sql_log_bin = 0 ;」と記述することで、スレーブにレプリケーションされなくなります。

二つ目は、スレーブを直接更新した場合、マスターには反映されないという点です。スレーブを読み取り専用の設定にすることは可能なものの、アプリ等からの更新を防ぐことはできないため、構成において気をつけなければなりません。

最後は、マスターとスレーブでそれぞれ実行した場合に異なる結果を返す関数があるという点です。FOUND_ROWS、GET_LOCK、IS_FREE_LOCK、 IS_USED_LOCK、 LOAD_FILE、MASTER_POS_WAIT、PASSWORD、RAND、RELEASE_LOCK、ROW_COUNT、SESSION_USER、SLEEP、SYSDATE、SYSTEM_USER、USER、UUID、UUID_SHORTといった関数が該当するのでご注意ください。

MySQLにおける非同期レプリケーション手順

まずはレプリケーション用のユーザーを作成しましょう。もちろんrootユーザーでもできますが、セキュリティ面からも基本的には専用ユーザーを作成します。なお作成方法は、MySQLのユーザを作成する際と同様です。

続いて、マスター側で初期値が無効となっているバイナリログの出力を「有効」に変更しましょう。また設定ファイルに、マスターのサーバーIDを任意の数字で設定する必要があります。設定ファイルは、WindowsOSの場合「my.ini」、UNIX系の場合「my.cnf」となります。設定したらサービスの再起動を行いましょう。スレーブ側でも同様にサーバーIDを任意の数字で設定し、サービスの再起動をします。なお設定するサーバーIDは、マスターや他のスレーブとは異なる数字で設定しましょう。

次にレプリケーション実施直前の作業を行います。マスター側で「SHOW MASTER STATUS;」を実行し、「バイナリログのファイル名」と「現在のポジション」を確認します。この時に確認した情報と、マスター側のホスト名、レプリケーション用ユーザー名/パスワード、読み取る対象ファイル等の情報をスレーブ側にも設定します。設定が完了したら再度サービスの再起動を行います。

ここまで完了したら、実際にレプリケーションを実施できます。なお、「mysqldump」を実施してレプリケーションの前にマスターのバックアップを取得しておくことをおすすめします。「mysqldump」を実行するとdumpファイルが取得できるので、スレーブ側にもこのdumpファイルを展開しておきます。

レプリケーションの準備が整ったらスレーブ側で「START SLAVE;」を実施し、マスター側へレプリケーショの開始リクエストを通知します。マスターはこのリクエストを受け取ると、更新内容が記録された情報をスレーブ側に転送します。今回は非同期の手順なので、以上でレプリケーションは完了となりますが、「同期」の場合は、スレーブが更新内容を受け取ると同時にデータベースに反映させることとなります。

まとめ

MySQL含めたデータベースにおいて、レプリケーションは非常に重要な機能ですが、今回の記事で設定・実行は特に複雑ではないことがわかっていただけたことでしょう。しかしながら同期等、正しく仕様を理解していないと取り返しのつかない自体になりかねない仕組みでもあるため、MySQLで初めてレプリケーションを実施する場合や久々に実施する場合は、この記事含め、仕様や注意点、手順を確認した上で慎重に実施しましょう。また、別のデータベースでレプリケーションを実施する場合は仕様が一部異なる場合もあるので、あらかじめ細部まで確認した上で実施することをおすすめします。