mariadbプライマリ・スレーブ・レプリケーション

4557 ワード
マリアード
背景
最近テンセントクラウドのサーバーをやめましたが、kvmのアーキテクチャを見ていると少し不安なので、ブログデータベースをアリクラウドの上に主従複製の災害バックアップをしました.
主従複製の原理
mariadb自体はmysqlと基本的に同じなので、mysqlとmariadbの方法は通用しますが、maraidbは自分のバージョン番号がmysqlより高いため、mysqlとmariadbをメインスレーブレプリケーションとして混用しないでください.また、プライマリ・データベースのバージョンがスレーブ・データベースより低いか、等しいかに注意してください.
mysqlがサポートするレプリケーションのタイプ:
  • 文ベースのレプリケーション:プライマリ・サーバ上で実行されるSQL文、サーバ上で同じ文を実行します.MySQLのデフォルトでは、文ベースのレプリケーションが採用されており、効率が高い.正確なレプリケーションができないことが判明すると、行ベースのレプリケーションが自動的に選択されます.
  • ローベースのレプリケーション:サーバからコマンドを1回実行するのではなく、変更されたコンテンツを過去にレプリケーションする.mysql 5から0サポート開始
  • ハイブリッドタイプのレプリケーション:デフォルトでは文ベースのレプリケーションが使用され、文ベースの正確なレプリケーションが発見されると、行ベースのレプリケーションが使用されます.

    • 全体的に、レプリケーションには3つのステップがあります.
  • masterは、変更をバイナリログ(binary log)に記録する(これらの記録をバイナリログイベント、binary log eventsと呼ぶ)
    • .
  • slaveはmasterのbinary log eventsをその中継ログ(relay log)にコピーする.
  • slaveは中継ログのイベントをやり直し、それ自体を反映するデータを変更します.

    • すなわち,合計3つのスレッドがプライマリ・セカンダリ・レプリケーション,プライマリ・サーバ1つのスレッド,サーバ2つのスレッドから起動される.
  • の第1の部分はmasterがバイナリログを記録することである.各トランザクションの更新データが完了する前に、masterはこれらの変更を2ログに記録します.MySQLは、トランザクションの文が交差している場合でも、トランザクションをバイナリ・ログにシリアル・ライトします.イベント書き込みバイナリ・ログが完了すると、masterはストレージ・エンジンにトランザクションのコミットを通知します.
  • 次はslaveがmasterのbinary logを独自の中継ログにコピーすることです.まず、slaveはワークスレッドであるI/Oスレッドを開始します.I/Oスレッドはmasterで通常の接続を開き、binlog dump processを開始します.Binlog dump processは、masterのバイナリ・ログからイベントを読み込み、masterについていると、睡眠をとり、masterが新しいイベントを生成するのを待っています.I/Oスレッドは、これらのイベントを中継ログに書き込みます.
  • SQL slave thread(SQLスレーブスレッド)このプロセスの最後のステップを処理します.SQLスレッドは、中継ログからイベントを読み出し、そのイベントを再生してslaveのデータを更新し、masterのデータと一致させる.このスレッドがI/Oスレッドと一致する限り、中継ログは通常OSのキャッシュに存在するため、中継ログのオーバーヘッドは小さい.

    • また、masterにもワークスレッドがあります.他のMySQLと同様に、slaveがmasterで接続を開くと、masterがスレッドを開始します.レプリケーションプロセスには重要な制限があります.レプリケーションはslave上でシリアル化されています.つまり、master上のパラレル更新操作はslave上でパラレルに操作できません.
    構成手順
    プライマリ・サーバ構成
    Masterのデータベースにバックアップアカウントを作成します.各slaveは標準のMySQLユーザー名とパスワードを使用してmasterに接続します.レプリケーションを行うユーザーには、REPLICATION SLAVE権限が付与されます.ユーザー名のパスワードはテキストファイルmasterに格納されます.infoのコマンドは次のとおりです.
    mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* 
TO backup@’10.100.0.200’ 
IDENTIFIED BY ‘1234’;

    Masterサーバを停止し、MasterのデータをBサーバにコピーして、Masterとslaveのデータを同期させ、すべての設定操作が終了する前に、Masterとslaveサーバでの書き込みを禁止し、両データベースのデータが必ず同じになるようにします.(mysqlプライマリ・セカンダリ・サーバを完全に新しくインストールした場合、このステップは必要ありません.新しくインストールしたmasterとslaveは同じデータがあるため)注意:必ずすべてのデータベースをコピーしなければなりません.プライマリ・セカンダリ・レプリケーションが必要なデータベースだけをコピーするのではなく、コールド・バックアップを推奨し、tarコマンドを通じてパッケージ化することをお勧めします.
    次に、バイナリ・ログを開き、一意のservr IDを指定するなど、masterを構成します.例えば、プロファイルにserver-id=1 log-bin=mysql-binserver-id:メインサーバAのID値log-bin:バイナリ変更日値でマスターを再起動し、SHOW MASTER STATUSを実行し、fileとpositionのパラメータを記録し、
    サーバからの構成
    Slaveの構成はmasterと同様で、slaveのMySQLを再起動する必要があります.次のようになります.
    log_bin           = mysql-bin
server_id         = 2
relay_log         = mysql-relay-bin
log_slave_updates = 1
read_only         = 1

    server_idは必須であり、唯一である.slaveはバイナリ・ログを開く必要はありませんが、場合によっては設定する必要があります.たとえば、slaveが他のslaveのmasterの場合、bin_を設定する必要があります.log.ここでは、バイナリ・ログを開き、表示される名前(デフォルト名はhostnameですが、hostnameが変更されると問題が発生します).relay_log構成中継ログ、log_slave_updatesはslaveがコピーイベントを自分のバイナリログに書き込むことを示します(後でその用途が表示されます).slaveのバイナリログを開いた人もいますが、logを設定していません.slave_updatesを使用して、slaveのデータが変更されたかどうかを確認します.これは誤った構成です.だから、できるだけread_を使いますonlyは、特殊なスレッドを除いてデータの変更を防止します.でも、read_onlyは実用的で、特にslave上でテーブルを作成する必要があるアプリケーションです.次にslaveにmasterに接続し、masterバイナリログのイベントのやり直しを開始します.プロファイルを使用するのではなく、CHANGE MASTER TO文を使用する必要があります.この文は、プロファイルの変更に完全に取って代わることができ、サーバを停止することなく、slaveに異なるマスターを指定することができます.次のようになります.
    mysql> CHANGE MASTER TO MASTER_HOST='server1',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='p4ssword',
    -> MASTER_LOG_FILE='mysql-bin.000001',
    -> MASTER_LOG_POS=0;

    master_log_posはさっき記録したpositionパラメータです.SHOW SLAVE STATUS文でslaveの設定が正しいかどうかを確認できます.
    mysql> SHOW SLAVE STATUS\G

    slaveがレプリケーションプロセスを開始していないことを示します.ログの場所は0ではなく4です.これは、0がログファイルの開始位置であり、ログの場所ではないためです.実際、MySQLが知っている最初のイベントの場所は4です.レプリケーションを開始するには、次の操作を行います.
    mysql> START SLAVE;

    SHOW SLAVE STATUSを実行して出力結果を確認する:
    mysql> SHOW SLAVE STATUS\G

    ここで主に見ます.
                   Slave_IO_Running=Yes
               Slave_SQL_Running=Yes

    slaveのI/OとSQLスレッドはすでに実行されており、Seconds_Behind_MasterはNULLではありません.ログの場所が増加したことは、いくつかのイベントが取得され、実行されたことを意味します.マスターで変更すると、slaveで様々なログファイルの位置の変化を見ることができます.同様に、データベース内のデータの変化も見ることができます.マスターとslave上のスレッドの状態を表示できます.
    さびストリング対
    211222