Mysql でのコピーの詳細な分析
- 小云云オリジナル
- 2017-12-08 11:59:571283ブラウズ
この記事では主に Mysql におけるレプリケーションの詳細な分析を紹介し、基本的な概念、使用法、実装方法、集中モードを紹介し、それを必要とする友人がそれについて学ぶことができる具体的な実装コードを共有します。
1.mysql レプリケーションの概念
は、プライマリ データベースの DDL および DML 操作をバイナリ ログを通じてレプリケーション サーバーに送信し、これらのログ ファイルをレプリケーション サーバー上で再実行することによって、レプリケーション サーバーを作成することを指します。とプライマリ サーバーのデータは同期されます。レプリケーション プロセス中、1 つのサーバーがマスターとして機能し、1 つ以上の他のサーバーがスレーブとして機能します。マスターはバイナリ ログ ファイルの更新を書き換え、ログ ローテーションを追跡するためにファイルのインデックスを維持します。これらのログは、スレーブ サーバーに送信された更新を記録します。スレーブはマスターに接続すると、スレーブがログから読み取った最後に成功した更新の場所をマスターに通知します。スレーブはそれ以降に発生した更新をすべて受け入れ、ブロックしてマスターに新しい更新が通知されるのを待ちます。
2. レプリケーションの目的
マスターとスレーブのレプリケーションを通じてデータを同期し、読み取りと書き込みの分離 (mysql-proxy) を通じてデータベースの同時負荷容量を向上させるか、データベースの設計として使用します。メイン マシンとバックアップ マシンにより、メイン マシンが応答を停止した後、アプリケーションをバックアップ マシンに切り替えて非常に短時間で実行を継続できるようになります。
利点:
(1) データベースクラスターシステムには複数のデータベースノードがあり、単一ノードに障害が発生した場合でも、他の正常なノードがサービスを提供し続けることができます。
(2) マスターサーバーに問題が発生した場合、スレーブサーバーに切り替えることができます
(3) レプリケーションによりクエリ操作をスレーブサーバーで実行できるため、マスターサーバーへのアクセス負荷が軽減され、データの分散と分散が実現しますロード バランシング
(4) バックアップ中にマスター サーバーのサービスに影響を与えることを避けるために、バックアップをスレーブ サーバーで実行できます。
3. レプリケーションの実装 (3 つの方法)
(1) DRBD は、サーバー間でブロック デバイスのコンテンツをミラーリングするためのソフトウェア実装のシェアードナッシング ストレージ レプリケーション ソリューションです。
(2) MySQL クラスター (mysql クラスターとも呼ばれます)。 Mysql のレプリケーション (replication) 自体は比較的単純な構造で、スレーブ サーバー (slave) がマスター サーバー (master) からバイナリ ログを読み取り、それを解析して自身に適用します。
(3) 単純なレプリケーション環境では、mysql を実行する 2 つのホストのみが必要で、1 つの物理サーバー ホスト上で 2 つの mysqld インスタンスを起動することもできます。 1 つはマスターとして機能し、もう 1 つはスレーブとして機能して、レプリケーション環境の構成を完了します。ただし、実際のアプリケーション環境では、mysql レプリケーション機能を使用して、最も一般的に使用されるマスター/スレーブ アーキテクチャなど、実際のビジネス ニーズに応じて拡張しやすい他のレプリケーション アーキテクチャを構築できます。
マスター/スレーブ アーキテクチャとは、1 つの mysql サーバーをマスターとして使用し、1 つ以上の mysql サーバーをスレーブとして使用し、マスターのデータをスレーブにコピーすることを指します。実際のアプリケーションでは、マスター/スレーブ アーキテクチャ モードが mysql レプリケーションに最も一般的に使用されます。一般に、このアーキテクチャでは、システムの書き込み操作はマスターで実行され、読み取り操作はさまざまなスレーブに分散されるため、このアーキテクチャは、現在のインターネットの大量の読み取りおよび書き込みの問題に特に適しています。
Mysqlデータベースのレプリケーション操作は大きく以下の手順に分かれます:
(1) マスターはバイナリログを有効にします。バイナリ ログを有効にする操作については、「ログ管理」で詳しく説明されています。
(2) スレーブ上の I/O プロセスはマスターに接続し、指定されたログ ファイルの指定された位置 (またはログの先頭) からログの内容を要求します。
(3) マスターはスレーブからのI/O処理要求を受信後、レプリケーションを担当するI/Oプロセスを通じて要求情報に従って指定されたログの指定位置以降のログ情報を読み出し、スレーブに返します。スレーブの I/O。ログに含まれる情報に加えて、返される情報には、bin ログ ファイルの名前と、返された情報がマスターに送信された bin ログの場所も含まれます。
(4) 情報を受信した後、スレーブの I/O プロセスは、受信したログの内容をスレーブ側のリレーログ ファイルの末尾に順番に追加し、ファイル名とビンの場所を記録します。読み取られたマスター側のログをマスター情報ファイルに記録します。
(5) スレーブの SQL プロセスがリレー ログの新しいコンテンツを検出すると、リレー ログのコンテンツをすぐに解析し、それ自体で実行します。
4. mysql レプリケーションの集中モード
mysql5.1 以降のバージョンでは、新しいレプリケーション テクノロジである行ベースのレプリケーションが導入され、レプリケーションが改善されました。このテクノロジーは、以前の binlog モードをコピーするのではなく、テーブル内で変更されたレコードに焦点を当てます。 mysql5.1.12 以降、これを実現するために次の 3 つのモードを使用できるようになりました。
(1) ステートメントベースのレプリケーション (sbr)
(2) 行ベースのレプリケーション (rbr)
(3) 混合モードのレプリケーション (mbr)
これに対応して、binlog にはステートメント、行、混合の 3 つの形式があります。 Mbr モードでは、sbr モードがデフォルトです。 binlog の形式は実行時に動的に変更できます。マスター/スレーブ レプリケーション モードを設定する方法は非常に簡単です。次のように、以前に設定したレプリケーション構成に基づいて別のパラメーターを追加するだけです。もちろん、実行時にバイナリ ログを動的に変更することもできます。形式
binlog_format=”statement” #binlog_format=”row” #binlog_format=”mixed”
マスター: 192.168.11.139
スレーブ: 192.168.11.130
(1 ) マスターサーバー:
Mysql> set session binlog_format=”statement”
メインサーバーでバイナリログを有効にします:
mysql> show variables like '%datadir%'; +---------------+--------------------------+ | Variable_name | Value | +---------------+--------------------------+ | datadir | /application/mysql/data/ | +---------------+--------------------------+
OFFはバイナリログがオフであることを意味します
①mysqlインストールディレクトリ/myを開きます.cnf
② ラベル [mysqld] を見つけ、このラベルの下の行に次のステートメントを追加します。
log_bin[filename]
mysql> show variables like 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | OFF | +---------------+-------+ row in set (0.00 sec)
指定したデータベースのバイナリ ファイル ログを生成しない場合は、次のステートメントを追加する必要があります。ステートメント
Binlog-do-db=db_name（数据库名称）
③mysqlサービスを再起動します。今後 mysql サービスが再起動されるたびに、mysql インストール ディレクトリ/データ フォルダーに「binary_log.numeric number」ファイルが表示されます。バイナリ ファイルは再生成され、その中に数値が表示されます。ファイル名が増えてしまいます。
正常に起動したら、mysql 設定ファイル my.cnf を変更し、サーバー ID を設定します。コードは次のとおりです
Binlog-ignore-db-db_name（数据库名称）
マスター上でレプリケーションに必要なユーザーを作成します
Server-id=1 Binlog-do-db=xscj Binlog-ignore-db=mysql Server-id=1：每一个数据库服务器都要指定一个唯一的server-id，通常主服务器为1，master和slave的server-id不能相同。 Binlog-do-db：表示需要复制的数据库，这里以xscj为例 Binlog-ignore-db：表示不需要复制的数据库
マスターホストのデータをバックアップし、/data/binary_dump.txt ファイルに保存して、スレーブマシンにインポートします。具体的な実行ステートメントは次のとおりです
mysql> grant replication slave on *.* to rep_user@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec
mysql> show master status\G
*************************** 1. row ***************************
File: binary_log.000001
Position: 303
Binlog_Do_DB:
Binlog_Ignore_DB:
row in set (0.00 sec)。
(2) スレーブサーバーの動作を制御する
スレーブサーバーのデータベース設定ファイルを変更します。設定は次のとおりです。
オプション
スレーブの開始
レプリケーションスレッドの開始
| レプリケーションスレッドを停止 |
スレーブをリセット |
| レプリケーション スレッドをリセット | スレーブ ステータスを表示 |
レプリケーション スレッド ステータスを表示 |
スレーブ ステータスを表示g |
レプリケーション スレッド ステータスを表示(別の行に表示) |
マスターのステータスを表示G |
|
マスターデータベースのステータスを表示（別の行に表示） マスターログを表示 processlistv |
どのスレッドが実行されているかを表示 |
| 学習しましたか？急いで試してみてください。 | 関連する推奨事項: |
| データテーブルのデータをMySQL_MySQLの新しいテーブルにコピーするための操作チュートリアル | MySQLレプリケーションの概要とインストール、障害、テクニック、ツール (Huo Ding が共有) |
以上がMysql でのコピーの詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。