目次
service mysql start
ログイン後にコピー
" >
service mysql start
ログイン後にコピー
6 混合模式复制
7 复制过滤
1. 基于master
2. 基于slave
8 日志清理
暴力清理:(没有主从复制的情况下)
条件清理
定时清理
写在最后
ホームページ データベース mysql チュートリアル mysqlマスタースレーブレプリケーション

mysqlマスタースレーブレプリケーション

Dec 03, 2020 pm 05:21 PM
mysql マスター/スレーブ レプリケーション

mysql ビデオ チュートリアル マスター/スレーブ レプリケーションを紹介するコラム

mysqlマスタースレーブレプリケーション

##関連する無料学習の推奨事項:

mysql ビデオ チュートリアル

データベース レプリケーションは、システムの高可用性とハイ パフォーマンスを向上させる上で非常に重要な役割を果たします。この記事では、mysql マスター/スレーブ レプリケーションに関連する関連知識をまとめています。この分野に携わっている方は、ぜひ参考にしていただければと思います。もっと詳しく知ることができます。役に立ちました。

1 メイン ライブラリ構成

1.1 my.cnf 構成:
メイン ライブラリ構成ファイル my.cnf で次の基本構成を構成します:

log-bin  =  mysql-bin //二进制日志文件名称主体
log-bin-index  =  mysql-bin.index //二进制日志文件索引文件
server-id  =  1 //唯一的服务器ID,为了保持唯一性,可以去ip的尾部
binlog-format  =  mixed //控制复制基于的方式,有基于语句(statement),基于行(row),混合(mixed),**主从库需要保持一致**
#sync_binlog=1 //推荐配置,开启该选项,mysql每次在事务提交前会将二进制日志同步到磁盘上,保证在服务器崩溃时不会丢失事件。
ログイン後にコピー
デフォルト すべてのデータベースをコピーします。データベースを指定する必要がある場合は、セクション 7 (コピー フィルタリング) を参照してください。

比如说要指定db1和db2两个数据库进行主从复制:
binlog-do-db = db1
binlog-do-db = db2
ログイン後にコピー
1.2 コピー アカウントを追加します:
コピー アカウントを追加して権限を設定します:

mysql> grant replication slave, replicatin client on \*.\* to repl@'172.16.226.192' identified by 'repl123456'; //其中repl是用户名,repl123456为账户密码,172.16.226.168为备库的地址。
mysql> flush privileges; //在不重启mysql服务的情况下完成权限的更新
ログイン後にコピー
2 スタンバイ データベース構成

スタンバイ データベース構成ファイル内my.cnf 次の基本設定を行います。

relay-log  =  slave-relay-bin //中继日志文件名称主体
relay-log-index  =  slave-relay-bin.index //中继日志文件索引文件
server-id  =  2 //唯一的服务器ID,必须要异于主库
#read_only = 1 //限制备库为只读,可选
log_slave_updates = 1 //控制是否在中继日志执行之后,将同步过来的数据添加到自己的binlog中去,1代表是
skip_slave_start // 该选项能够阻止备库在崩溃后自动启动复制,建议开启
即使开启了建议的选项,备库仍然可能在崩溃后被中断,因为master.info和中级日志文件都不是崩溃安全的,所以建议开启一下选项:
sync_master_info     = 1
sync_relay_log       = 1
sync_relay_log_info  = 1
ログイン後にコピー
同期するデータベースまたはテーブルをフィルタリングすることもできます。レプリケーションのフィルタリングに関するセクションを参照してください。

3 データベース リモート バックアップ

データベース リモート バックアップでは、ホット バックアップに mysqldump (論理バックアップ) を選択できますが、データ量が多い場合は遅くなります。Xtrabackup (物理バックアップ) も選択できます。 mysql でホット バックアップを実行する データベースはホット バックアップを実行します (ここでは innobackupex-1.5.1 を使用します) Xtrabackup は、innoDB などのデータベースのオンライン バックアップを実現し、高速で通常の読み書きに影響を与えません。ここでデータベース全体をバックアップします。

3.1 バックアップ アカウントの作成
データベース バックアップ用にメイン サーバーにユーザー バックアップを作成します (最小限の権限を使用します)。

mysql> grant reload, lock tables, replication client on \*.\* to backup@'%' identified by 'backup123';
mysql> flush privileges; //在不重启mysql服务的情况下完成权限的更新
ログイン後にコピー
3.2 データベースの完全バックアップ
完全バックアップとリカバリの準備の両方の手順は、メイン データベース サーバー上で完了します。

innobackupex-1.5.1 --defaults-file=/etc/mysql/my.cnf --user=backup --password=backup123  /mysqlbackup
--defaults-file:选择默认的配置文件
--user和--password:分别为进行备份的用户名和密码
/mysqlbackup:目标目录
ログイン後にコピー
3.3 リカバリの準備
通常、バックアップの完了後、バックアップされたデータにはまだコミットされていないトランザクションまたはコミットされたトランザクションが含まれている可能性があるため、そのデータをリカバリ操作に使用することはできません。ただし、データ ファイル内のトランザクションにはまだ同期されていません。したがって、現時点ではデータ ファイルは依然として不整合な状態に対処しています。 「準備」の主な機能は、コミットされていないトランザクションをロールバックし、コミットされたトランザクションをデータ ファイルに同期することによって、データ ファイルを一貫した状態にすることです。

innobakupex コマンドの --apply-log オプションを使用して、上記の機能を実装できます。たとえば、次のコマンド:

innobackupex-1.5.1 --apply-log --user=backup --password=backup123  /mysqlbackup/2017-01-11_21-20-57
如果执行正确,其最后输出的几行信息通常如下:
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120407  9:01:36  InnoDB: Starting shutdown...
120407  9:01:40  InnoDB: Shutdown completed; log sequence number 92036620
120407 09:01:40  innobackupex: completed OK!
ログイン後にコピー
「準備」を実装するプロセスで、innobackupex は通常、 --use-memory オプションを使用して、使用できるメモリのサイズを指定することもできます。通常、デフォルトは次のとおりです。 100M。十分なメモリが利用可能な場合は、準備プロセスにより多くのメモリを割り当てて、完了速度を向上させることができます。

3.4 データコピー
マスターサーバーに用意したデータベースをスレーブサーバーにコピーします。 (もちろん、パッケージ化してからコピーすることもできます)

scp -r /mysqlbackup/ copyer@192.168.1.192:/data/
ログイン後にコピー
3.5 データ回復

データ回復の前に、まずスレーブ サーバーの mysql サービスを閉じ、次の xtrabackup_binlog_info ファイルからデータを取得します。バックアップ フォルダー 現在使用されているバイナリ ログ ファイル、およびこの時点までのバイナリ ログ イベントがバックアップされる場所。 datadir ディレクトリが空でない場合は、datadir ディレクトリもクリアする必要があります。 innobackupex コマンドの --copy-back オプションは、リカバリ操作を実行するために使用され、すべてのデータ関連ファイルを mysql サーバーの datadir ディレクトリにコピーすることによってリカバリ プロセスを実行します。 innobackupex は、backup-my.cnf を通じて datadir ディレクトリに関する関連情報を取得します (--defaults-file を通じて my.cnf ディレクトリを指定し、datadir パスが空であることを確認することもできます)

innobackupex-1.5.1 --copy-back  /mysqlbackup
如果执行正确,其输出信息的最后几行通常如下:
innobackupex: Starting to copy InnoDB log files
innobackupex: in '/backup/2012-04-07_08-17-03'
innobackupex: back to original InnoDB log directory '/mydata/data'
innobackupex: Finished copying back files.
120407 09:36:10  innobackupex: completed OK!
ログイン後にコピー
確認してください上記情報の最後の部分に「innobackupex: completed OK!」という行が表示されます。

データを datadir ディレクトリに復元した後、すべてのデータ ファイルの所有者とグループが mysql などの正しいユーザーであることを確認する必要があります。そうでない場合は、データ ファイルの所有者を変更する必要があります。 mysqld. とグループを開始する前に。例:

chown -R  mysql:mysql  /var/lib/mysql/
ログイン後にコピー
4 マスター/スレーブ接続

4.1 スレーブ データベースを開きます
service mysql start
ログイン後にコピー
mysql を開くのに失敗した場合は、エラーを確認することで失敗の理由を見つけることができます。ログ。

4.2 マスター/スレーブ接続を確立する
スレーブ ライブラリは、レプリケーション アカウントを介してマスター ライブラリに接続します: (次の接続を有効にするには、スレーブが停止状態である必要があります)

mysql> change master to master_host='192.168.1.208',master_user='repl',
master_password='repl123456',master_log_file='mysql-bin.000001'(备份时得到的活动日志),master_log_pos=0(备份时得到的活动日志中事件的位置);
ログイン後にコピー

注 : マスター/スレーブ接続中にマスターをここに接続できない場合、考えられる理由の 1 つは、ローカル マシンが my.cnf 構成ファイル (つまり、bind-address) でバインドされていることです。 = 127.0.0.1. やるべきこと コメントアウトするだけで、そうしないと外部マシンがアクセスできなくなります。

オープン スレーブ:

mysql> start slave;
ログイン後にコピー
スレーブのステータスを確認すると、IO スレッドと SQL スレッドがすでにオープン状態にあり、スレーブの接続ステータスを表す変数が多数あることがわかります。スレーブ ライブラリ (これらの変数はマスター/スレーブ監視の設定にも使用できます) については、ここでは 1 つずつ紹介しません。

mysql> show slave status;

Slave_IO_Running: Yes  //表示IO线程运行正常
Slave_SQL_Running: Yes  //表示SQL线程运行正常
Seconds_Behind_Master: 0  //表示在网络条件较好的情况下,从库能够及时同步上主库
ログイン後にコピー
4.3 共通監視コマンド
mysql> show processlist\G; //查看数据库服务线程情况
mysql> show master/slave status\G; //查看主备库状态
mysql> flush logs; //强制轮换(rotate)二进制日志,从而得到一个完整的二进制日志文件
mysql> show binlog events in '指定二进制日志文件名称'  from (从指定位置开始显示) limit (需要显示的事件数量)\G; //查看binlog中事件
mysql> show binary logs; //显示所有的binlogs
mysql> reset master; //删除所有二进制日志文件并清空索引文件
mysql> reset slave; //删除slave上复制用的所有文件重新开始
mysql> show slave hosts;  //查看主库所拥有的从库信息
ログイン後にコピー

mysqlマスタースレーブレプリケーション

5 スレーブライブラリの遅延が大きい

スレーブライブラリの遅延が大きい場合、大幅な遅延の理由を見つける必要があります。パラメータ innodb_flush_log_at_trx_commit は、mysql の書き込み効率に大きな影響を与え、次の 3 つの値があります。
0:每隔一秒,把事务日志缓存区的数据写到日志文件中,以及把日志文件的数据刷新到磁盘上;
1:每个事务提交时候,把事务日志从缓存区写到日志文件中,并且刷新日志文件的数据到磁盘上;
2:每事务提交的时候,把事务日志数据从缓存区写到日志文件中;每隔一秒,刷新一次日志文件,但不一定刷新到磁盘上,而是取决于操作系统的调度;
ログイン後にコピー

取1时的IO耗费最大,虽然一致性和完整性方面效果最好,但是写入效率最低,而这也是导致从库延迟较大的原因(如果服务器配置较高或许会好些)。取0时mysql写入性能很好,但如果 mysqld 进程崩溃,通常会导致最后 1s 的日志丢失 。取2时的写入性能也很好,每次事务提交会写入日志文件,但并不会立即刷写到磁盘,日志文件会每秒刷写一次到磁盘。这时如果 mysqld 进程崩溃,由于日志已经写入到系统缓存,所以并不会丢失数据;在操作系统崩溃的情况下,通常会导致最后 1s 的日志丢失。

6 混合模式复制

正常情况下使用使用基于语句的复制,而对不安全的语句则切换到基于行的复制。主要有以下几种情况:

  1. 该语句调用了:
    • UUID函数
    • 用户自定义函数
    • CURRENT_USER或USER函数
    • LOAD_FILE函数
  2. 一个语句同时更新了两个或者两个以上含有AUTO_INCREMENT列的表
  3. 语句使用了服务器变量
  4. 存储引擎不允许使用基于语句的复制,例如,mysql cluster引擎

7 复制过滤

有时候我们不需要对数据库中所有的库进行复制,或者不想对指定库中的某些表进行复制操作,那么我们就需要对复制进行一定的过滤配置,以达到更合理的复制效果。

1. 基于master
**binlog-do-db=mysql**:主库只是将指定库(mysql)发生的变化记录到二进制日志中。
**binlog-ignore-db=mysql**:主库取消将指定库(mysql)发生的变化记录到二进制日志中。
ログイン後にコピー
2. 基于slave

针对数据库进行的过滤:

**replicate-do-db=mysql**:从库只是将指定库(mysql)发生的变化进行重现。
**replicate-ignore-db=mysql**:从库取消将指定库(mysql)发生的变化进行重现。
针对表进行的过滤:
**replicate-wild_do-table=mysql.learn**:从库只是将指定库(mysql)中指定表(learn)发生的变化进行重现。
**replicate-wild_ignore-table=mysql.learn**:从库取消将指定库(mysql)中指定表(learn)发生的变化进行重现。
ログイン後にコピー

以上复制过滤方式乍一看没有问题,其实还是有需要注意的地方。因为这些过滤方式的效果与复制方式有关系。如果是基于语句的复制,binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db与跨库(如use库内和use外)有关系,这一点需要注意。

8 日志清理

暴力清理:(没有主从复制的情况下)
1、重启mysql服务器即可关闭bin日志的记录
2、通过reset master命令进行清理
ログイン後にコピー
条件清理

如果存在主从复制关系,则应当使用purge的方式来清理bin日志,语法如下:

purge {master|binary} logs to 'log_name'
purge {master|binary} logs before 'date'
ログイン後にコピー

用户删除列于在指定的日志或日期之前的日志索引中的所有二进制日志,同时这些日志也会从日志索引文件的清单中删除。

eg.
purge master logs to 'mysql-bin.000005';
purge master logs before '2014-08-30 00:00:00';//清除指定日期之前的日志
purge master logs before date_sub(now(),Interval 3 day);清除三天前的日志
ログイン後にコピー
定时清理

参数:expire_logs_days
说明:二进制日志自动删除/过期的天数。默认值为'0',即没有过期的
示例:expire_logs_days = 5,代表日志的有效时间为5天
什么时候会删除过期日志?

每次进行log flush的时候会自动删除过期的日志
ログイン後にコピー

什么时候会触发log flush?

1、重启
2、binlog文件的大小达到了最大限制
3、手动执行flush logs命令
ログイン後にコピー

写在最后

本文只是结合自己的学习以及实践过程进行了相关总结,如有不妥之处望您批评指正。推荐大家学习《高可用MYSQL》、《高性能MYSQL》两本书,最重要的还是实践实践再实践,欢迎交流,共同进步。

想了解更多编程学习,敬请关注php培训栏目!

以上がmysqlマスタースレーブレプリケーションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、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テーブルロックテーブルを変更するかどうか Apr 08, 2025 pm 05:06 PM

MySQLがテーブル構造を変更すると、メタデータロックが通常使用され、テーブルがロックされる可能性があります。ロックの影響を減らすために、次の測定値をとることができます。1。オンラインDDLでテーブルを使用できます。 2。バッチで複雑な変更を実行します。 3.小規模またはオフピーク期間中に操作します。 4. PT-OSCツールを使用して、より細かい制御を実現します。

MySQLユーザーとデータベースの関係 MySQLユーザーとデータベースの関係 Apr 08, 2025 pm 07:15 PM

MySQLデータベースでは、ユーザーとデータベースの関係は、アクセス許可と表によって定義されます。ユーザーには、データベースにアクセスするためのユーザー名とパスワードがあります。許可は助成金コマンドを通じて付与され、テーブルはCreate Tableコマンドによって作成されます。ユーザーとデータベースの関係を確立するには、データベースを作成し、ユーザーを作成してから許可を付与する必要があります。

mysqlは支払う必要がありますか mysqlは支払う必要がありますか Apr 08, 2025 pm 05:36 PM

MySQLには、無料のコミュニティバージョンと有料エンタープライズバージョンがあります。コミュニティバージョンは無料で使用および変更できますが、サポートは制限されており、安定性要件が低く、技術的な能力が強いアプリケーションに適しています。 Enterprise Editionは、安定した信頼性の高い高性能データベースを必要とするアプリケーションに対する包括的な商業サポートを提供し、サポートの支払いを喜んでいます。バージョンを選択する際に考慮される要因には、アプリケーションの重要性、予算編成、技術スキルが含まれます。完璧なオプションはなく、最も適切なオプションのみであり、特定の状況に応じて慎重に選択する必要があります。

高負荷アプリケーションのMySQLパフォーマンスを最適化する方法は? 高負荷アプリケーションのMySQLパフォーマンスを最適化する方法は? Apr 08, 2025 pm 06:03 PM

MySQLデータベースパフォーマンス最適化ガイドリソース集約型アプリケーションでは、MySQLデータベースが重要な役割を果たし、大規模なトランザクションの管理を担当しています。ただし、アプリケーションのスケールが拡大すると、データベースパフォーマンスのボトルネックが制約になることがよくあります。この記事では、一連の効果的なMySQLパフォーマンス最適化戦略を検討して、アプリケーションが高負荷の下で効率的で応答性の高いままであることを保証します。実際のケースを組み合わせて、インデックス作成、クエリ最適化、データベース設計、キャッシュなどの詳細な主要なテクノロジーを説明します。 1.データベースアーキテクチャの設計と最適化されたデータベースアーキテクチャは、MySQLパフォーマンスの最適化の基礎です。いくつかのコア原則は次のとおりです。適切なデータ型を選択し、ニーズを満たす最小のデータ型を選択すると、ストレージスペースを節約するだけでなく、データ処理速度を向上させることもできます。

RDS MySQL Redshift Zero ETLとの統合 RDS MySQL Redshift Zero ETLとの統合 Apr 08, 2025 pm 07:06 PM

データ統合の簡素化:AmazonrdsmysqlとRedshiftのゼロETL統合効率的なデータ統合は、データ駆動型組織の中心にあります。従来のETL(抽出、変換、負荷)プロセスは、特にデータベース(AmazonrdsmysQlなど)をデータウェアハウス(Redshiftなど)と統合する場合、複雑で時間がかかります。ただし、AWSは、この状況を完全に変えたゼロETL統合ソリューションを提供し、RDSMYSQLからRedshiftへのデータ移行のための簡略化されたほぼリアルタイムソリューションを提供します。この記事では、RDSMysQl Zero ETLのRedshiftとの統合に飛び込み、それがどのように機能するか、それがデータエンジニアと開発者にもたらす利点を説明します。

MySQLのクエリ最適化は、特に大規模なデータセットを扱う場合、データベースのパフォーマンスを改善するために不可欠です MySQLのクエリ最適化は、特に大規模なデータセットを扱う場合、データベースのパフォーマンスを改善するために不可欠です Apr 08, 2025 pm 07:12 PM

1.正しいインデックスを使用して、データの量を削減してデータ検索をスピードアップしました。テーブルの列を複数回検索する場合は、その列のインデックスを作成します。あなたまたはあなたのアプリが基準に従って複数の列からのデータが必要な場合、複合インデックス2を作成します2。選択した列のみを避けます。必要な列のすべてを選択すると、より多くのサーバーメモリを使用する場合にのみサーバーが遅くなり、たとえばテーブルにはcreated_atやupdated_atやupdated_atなどの列が含まれます。

MySQLのユーザー名とパスワードを入力する方法 MySQLのユーザー名とパスワードを入力する方法 Apr 08, 2025 pm 07:09 PM

MySQLのユーザー名とパスワードを入力するには:1。ユーザー名とパスワードを決定します。 2。データベースに接続します。 3.ユーザー名とパスワードを使用して、クエリとコマンドを実行します。

MySQL:初心者向けのデータ管理の容易さ MySQL:初心者向けのデータ管理の容易さ Apr 09, 2025 am 12:07 AM

MySQLは、インストールが簡単で、強力で管理しやすいため、初心者に適しています。 1.さまざまなオペレーティングシステムに適した、単純なインストールと構成。 2。データベースとテーブルの作成、挿入、クエリ、更新、削除などの基本操作をサポートします。 3.参加オペレーションやサブクエリなどの高度な機能を提供します。 4.インデックス、クエリの最適化、テーブルパーティション化により、パフォーマンスを改善できます。 5。データのセキュリティと一貫性を確保するために、バックアップ、リカバリ、セキュリティ対策をサポートします。

See all articles