MySQL5.5各架构复制

Jun 07, 2016 pm 05:21 PM
mysqlマスタースレーブレプリケーション

实现主服务器和从服务器之间的数据复制,关于mysql的安装这里不在重复叙述,如有需要可参考其他文档,这里假设两个节点的服务器已

本文档将要介绍的内容:

    1、mysql的主从复制的配置
    2、配置半同步
    3、基于SSL的复制
    4、复制过滤
    5、主主模型
 
一、系统环境
 
master: 192.168.56.101
slave:  192.168.56.102
基于MySQL-5.5.24
实现主服务器和从服务器之间的数据复制,关于mysql的安装这里不在重复叙述,如有需要可参考其他文档,这里假设两个节点的服务器已经安装完成并能够正常启动。
 
二、配置的mysql主从复制
 
1、配置主服务器
 
 
1.1、编辑MySQL主配置文件
[root@master ~]# vim /etc/my.cnf    //编辑配置文件确保有以下两行
 
log-bin=mysql-bin //定义开启二进制日志
server-id       = 1 //定义server-id,主从服务器的id不能一样
 
1.2、建立具有复制权限的用户
[root@master ~]# /usr/local/mysql/bin/mysql -uroot -p
mysql> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO cpmysql@'192.168.56.102' IDENTIFIED BY 'cpmysql'; //创建cpmysql用户并设置密码为cpmysql
mysql> FLUSH PRIVILEGES;    //刷新授权表
 
查看当前使用的二进制文件和Posotions数值,后边在从服务器上要设置这两个值
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      358 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.05 sec)
 
 
2、配置从服务器
 
2.1、编辑MySQL主配置文件
[root@slave ~]# vim /etc/my.cnf
 
#log-bin=mysql-bin //可选,关闭二进制日志文件
server-id       = 11 //定义server-id不能和主服务器相同
relay-log=mysql-relay //开启中继日志且名称为mysql-relay
 
[root@slave ~]# service mysqld restart  //重新启动mysql以使新配置生效
[root@slave ~]# /usr/local/mysql/bin/mysql -u root -p //以root用户登录mysql
确认relay_log已开启:
mysql> SHOW GLOBAL VARIABLES LIKE 'relay_log';
+---------------+-------------+
| Variable_name | Value       |
+---------------+-------------+
| relay_log     | mysql-relay |
+---------------+-------------+
1 row in set (0.00 sec)
 
确认server_id配置生效其直不能与主服务器相同
mysql> SHOW GLOBAL VARIABLES LIKE 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 11    |
+---------------+-------+
1 row in set (0.00 sec)
 
2.2、配置主服务器相关参数
mysql> CHANGE MASTER TO MASTER_HOST='192.168.56.101',MASTER_USER='cpmysql',MASTER_PASSWORD='cpmysql',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=358;
说明:MASTER_LOG_FILE和MASTER_LOG_POS参数的值要和上边在主服务器上查询到的值一致。
 
启动从服务器进程
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)
 
查询从服务器状态,能看到Slave_IO_Running和Slave_SQL_Running两个进程运行状态为Yes
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.56.101
                  Master_User: cpmysql
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 358
               Relay_Log_File: mysql-relay.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
     ...
如果出现其他异常情况造成不能启动,可查看mysql的错误日志,里边有详细的错误信息,例如这里为/mysqldata/slave.err
 
3、测试主从复制配置是否成功
 
在主服务器上创建一个数据库testdb
[root@master ~]# /usr/local/mysql/bin/mysql -u root -p
mysql> CREATE DATABASE testdb;
Query OK, 1 row affected (0.01 sec)
 
在从服务器上查看是否已经成功复制过来
mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| testdb             |
+--------------------+
5 rows in set (0.05 sec)
可以看到已经成功复制。
 
4、一些建议配置
 
4.1、在主服务器上开启随时同步二进制日志至文件中,默认主服务器生成的二进制日志先放在缓存中,而从服务器需要靠主服务器上生成的二进制文件来保持和主服务器的一致,所以应该让主服务器产生二进制文件后立即同步至二进制日志文件中。
 
修改MySQL的主配置文件my.cnf添加如下行:
[root@master ~]# vim /etc/my.cnf
 
sync_binlog=1
 
[root@master ~]# service mysqld restart    //重启mysql服务使配置生效
在主服务器上查询参数是否生效
mysql> SHOW GLOBAL VARIABLES LIKE 'sync_binlog';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 1     |
+---------------+-------+
1 row in set (0.00 sec)
 
4.2、适用于innodb引擎,使没一次产生的事务日志同步到磁盘之后才返回成功,这样可以有助于保证事务日志的安全性,避免因为特殊原因造成事务日志的丢失,但这样也会降低在执行大量需要记录事务日志操作时的执行速度。
 
修改Mysql的主配置文件my.cnf添加如下行:
[root@master ~]# vim /etc/my.cnf
 
innodb_flush_logs_at_trx_commit=1
 
4.3、设置从服务器为只读,避免误操作造成主从服务器的数据不一致
 
[root@slave ~]# vim /etc/my.cnf
 
read_only=1
 
5、如果主服务器运行了一段时间,从服务器为新增的服务器时就不能根据以上方法来配置了,需要现在主服务器上备份:
 
先在主服务器上给mysql施加读锁
mysql> FLUSH TABLES WITH READ LOCK; 
Query OK, 0 rows affected (0.00 sec)
 
通过逻辑卷创建快照备份mysql,这里假设mysql的数据目录的挂载的设备为/dev/mysqlvg/mysqllv
[root@master ~]# lvcreate -L 50M -s -p r -n mysql-snap /dev/mysqlvg/mysqllv
 
在逻辑卷上创建好快照之后查看当前mysqld的二进制文件及Position的数值,完成后立即释放之前施加的读锁
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      478 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
 
释放读锁:
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)
 
挂载刚创建的逻辑卷快照并备份至从服务器
[root@master ~]# mount /dev/mysqlvg/mysql-snap /mnt
[root@master ~]# tar cf allmysql.tar /mnt/ //如果数据文件过大就压缩
 
拷贝该归档文件至从服务器,把内容覆盖至从服务器mysql的数据目录,并移除逻辑卷快照
[root@master ~]# umount /mnt
[root@master ~]# lvremove /dev/mysqlvg/mysql-snap  
 
其他步骤与上边的从服务器配置相同,参考-->2.2、配置主服务器相关参数,,注意替换:MASTER_LOG_FILE和MASTER_LOG_POS参数的值为释放读锁时查看到的信息。
 
至此就可以实现主从复制了。

linux

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

データのバックアップと障害復旧: クラスター モードでの MySQL マスター/スレーブ レプリケーションの重要性についてのディスカッション データのバックアップと障害復旧: クラスター モードでの MySQL マスター/スレーブ レプリケーションの重要性についてのディスカッション Sep 08, 2023 am 09:03 AM

データのバックアップと障害回復: クラスター モードでの MySQL マスター/スレーブ レプリケーションの重要性についての議論 はじめに: 近年、データの規模と複雑さが継続的に増大するため、データベースのバックアップと障害回復が特に重要になってきています。分散システムでは、高可用性とフォールト トレランスを提供するために、MySQL マスター/スレーブ レプリケーションがクラスター モードで広く使用されています。この記事では、クラスター モードでの MySQL マスター/スレーブ レプリケーションの重要性を検討し、いくつかのコード例を示します。 1. MySQL マスター/スレーブ レプリケーションの基本原理と利点 MySQL マスター/スレーブ レプリケーションは、一般的な

高い同時実行性に簡単に対処: クラスター テクノロジとしての MySQL マスター/スレーブ レプリケーションのパフォーマンス上の利点の分析 高い同時実行性に簡単に対処: クラスター テクノロジとしての MySQL マスター/スレーブ レプリケーションのパフォーマンス上の利点の分析 Sep 10, 2023 pm 03:48 PM

高い同時実行性に簡単に対処: クラスター テクノロジとしての MySQL マスター/スレーブ レプリケーションのパフォーマンス上の利点の分析 インターネットの急速な発展に伴い、Web サイトやアプリケーションへのユーザーのアクセス数は爆発的な増加傾向を示しています。このような同時実行性の高い状況では、システムの安定性とパフォーマンスをどのように確保するかが、すべての開発者とシステム管理者にとって重要な課題となっています。データベースでは、MySQL のマスター/スレーブ レプリケーション テクノロジが広く使用されており、高い同時実行性に対処する効果的なソリューションの 1 つとなっています。この記事では、クラスター テクノロジとしての MySQL マスター/スレーブ レプリケーションのパフォーマンス上の利点について説明します。初め

データベースのパフォーマンスの最適化: クラスター テクノロジで MySQL マスター/スレーブ レプリケーションを使用する最良の方法 データベースのパフォーマンスの最適化: クラスター テクノロジで MySQL マスター/スレーブ レプリケーションを使用する最良の方法 Sep 10, 2023 am 08:24 AM

データベース パフォーマンスの最適化: クラスター テクノロジで MySQL マスター/スレーブ レプリケーションを使用する最良の方法 要約: インターネットの急速な発展に伴い、データベース パフォーマンスの問題がさまざまな企業や組織の焦点になっています。 MySQL のマスター/スレーブ レプリケーション テクノロジーは、データベースのパフォーマンスのボトルネックを解決する上で重要な役割を果たします。この記事では、読者がデータベースのパフォーマンスを最適化できるように、MySQL マスター/スレーブ レプリケーションの概念と原則、およびクラスター テクノロジの最適な使用方法を紹介します。 1. はじめに データ量が増加し続けるにつれて、データベースのパフォーマンスの問題がますます顕著になってきています。数値を最適化する方法

MySQL マスター/スレーブ レプリケーションの解読: クラスター モードでの主要な実装メカニズムを明らかにする MySQL マスター/スレーブ レプリケーションの解読: クラスター モードでの主要な実装メカニズムを明らかにする Sep 10, 2023 am 09:28 AM

MySQL マスター/スレーブ レプリケーションの解読: クラスター モードでの主要な実装メカニズムを明らかにする はじめに: 最新のデータベース システムでは、データの高可用性と柔軟性が非常に重要です。オープンソースのリレーショナル データベース管理システムとして、MySQL にはユーザーのニーズを満たす幅広いアプリケーションがあります。 MySQL のマスター/スレーブ レプリケーションは、MySQL データベース アーキテクチャの非常に重要な部分であり、データのバックアップと高可用性を実現するために使用されます。この記事では、特にクラスター モードにおける MySQL マスター/スレーブ レプリケーションの主要な実装メカニズムを明らかにすることに焦点を当てます。

MySQL のマスター/スレーブ レプリケーションはクラスター テクノロジですか、それともロード バランシング テクノロジですか?分析と違い MySQL のマスター/スレーブ レプリケーションはクラスター テクノロジですか、それともロード バランシング テクノロジですか?分析と違い Sep 10, 2023 am 08:40 AM

MySQL のマスター/スレーブ レプリケーションはクラスター テクノロジですか、それともロード バランシング テクノロジですか?分析と相違点の概要: MySQL マスター/スレーブ レプリケーションは、複数のサーバー上のデータベース データを同期するために使用されるデータベース レプリケーション テクノロジです。この記事では、MySQL のマスター/スレーブ レプリケーション、クラスター テクノロジ、およびロード バランシング テクノロジの違いを、技術原則、アプリケーション シナリオ、機能特性の観点から分析して区別します。はじめに: 最新のインターネット アプリケーションでは、データベースの高可用性とスケーラビリティが非常に重要です。 MySQL のマスター/スレーブ レプリケーションは一般的なソリューションの 1 つですが、

クラスタ技術におけるMySQLマスタースレーブレプリケーションの機能とメリットを詳しく解説 クラスタ技術におけるMySQLマスタースレーブレプリケーションの機能とメリットを詳しく解説 Sep 09, 2023 am 09:03 AM

クラスタテクノロジにおける MySQL マスタースレーブレプリケーションの機能と利点の詳細な説明 はじめに MySQL は、さまざまな大規模な Web サイトやアプリケーションで広く使用されている強力なリレーショナル データベース管理システムです。データ量が増加し、アクセス要求が増加するにつれて、単一の MySQL サーバーにかかる負荷が徐々に増大し、データベースのパフォーマンスと信頼性を向上させるために、クラスター テクノロジが採用され始めています。一般的に使用されるテクノロジーを意味します。 MySQL のマスター/スレーブ レプリケーションの原則 MySQL のマスター/スレーブ レプリケーションとは、

MySQL マスター/スレーブ レプリケーションにおけるクラスター テクノロジーの可能性を明らかにする: オープンソース ソリューションと商用ソリューションの比較評価 MySQL マスター/スレーブ レプリケーションにおけるクラスター テクノロジーの可能性を明らかにする: オープンソース ソリューションと商用ソリューションの比較評価 Sep 08, 2023 pm 07:16 PM

MySQL マスター/スレーブ レプリケーションのクラスター テクノロジーの可能性の活用: オープン ソース ソリューションと商用ソリューションの比較評価 インターネット ビジネスの継続的な発展とデータ量の増加に伴い、データベース クラスター ソリューションに対する需要がますます高まっています。 MySQL のマスター/スレーブ レプリケーション テクノロジは、まさにこの要求に応え、データベースの読み取りおよび書き込み操作を複数のノードで個別に処理できるため、データベースの読み取りパフォーマンスと可用性が向上します。この記事では、MySQL マスター/スレーブ レプリケーションにおけるクラスター テクノロジーの可能性を探り、オープン ソース ソリューションと商用ソリューションの比較評価を実施します。

MySQL マスター/スレーブ レプリケーションのクラスター機能と非ロード バランシング アプリケーション シナリオを理解する MySQL マスター/スレーブ レプリケーションのクラスター機能と非ロード バランシング アプリケーション シナリオを理解する Sep 11, 2023 am 11:04 AM

インターネットの急速な発展に伴い、アプリケーション システムのデータ量は増加しており、データベースのパフォーマンスと信頼性に対する要件もますます高くなっています。 MySQL は、最も一般的に使用されているオープン ソース リレーショナル データベースの 1 つであり、高いパフォーマンスと安定性を備えており、さまざまなエンタープライズ レベルのアプリケーションで広く使用されています。一般的に使用されるデータ レプリケーション ソリューションとして、MySQL マスター/スレーブ レプリケーションはデータの信頼性と読み取りおよび書き込みパフォーマンスを向上させることができ、大規模なデータ アプリケーションで広く使用されています。 MySQL マスター/スレーブ レプリケーションのクラスター機能とは、レプリケーション メカニズムを通じてマスター データベースのデータを同期することを指します。

See all articles