MySql の運用とメンテナンス ---008: ログ: エラー ログ、バイナリ ログ、クエリ ログ、スロー クエリ ログ、マスター/スレーブ レプリケーション: 仮想マシンの IP を変更するための注意事項、原則、および構築手順の概要

情報 2023-10-05 09:54:09 訪問数: null

1.ログ

1.1 エラーログ

エラー ログは MySQL の最も重要なログの 1 つで、 mysqld の起動時と停止時、およびサーバーの実行中に重大なエラーが発生したときに関連情報が記録されます。データベースに正常な使用を妨げる障害が発生した場合は、まずこのログを確認することをお勧めします。

ログはデフォルトで有効になっており、デフォルトのディレクトリ /var/log/ に保存されます。デフォルトのログ ファイル名は mysqld.log です。ログの場所を確認します。

#先登录mysql
mysql -uroot -p1234

#通过此系统变量查看日志文件的位置
show variables like '%log_error%';

ここに画像の説明を挿入します

#通过tail指令查看文件尾部的50行日志
tail -n 50 /var/log/mysqld.log

ここに画像の説明を挿入します

1.2 バイナリログ

1.2.1 はじめに

バイナリ ログ (BINLOG) には、すべての DDL (データ定義言語: データベースの作成...) ステートメントと DML (データ操作言語: 追加、削除、変更) ステートメントが記録されますが、データ クエリ (SELECT、SHOW ) ステートメントは含まれません。

効果：

  • ①. 災害時のデータ復旧。
    • バイナリ ログにはデータベース、テーブル、データへの変更が記録されるためです。データを復元するには、ここでステートメントを再度実行するだけです。
  • ②. MySQL のマスター/スレーブ レプリケーション。MySQL8バージョンの場合
    • マスター/スレーブ レプリケーションの基本原理はバイナリ ログに基づいています。詳細については、次の章を参照してください。

mysql8.0 バージョンのデフォルトのバイナリ ログはオンになっており、関連するパラメータは次のとおりです。

#先登录mysql
mysql -uroot -p1234

#通过此系统变量来查看二进制日志相关的参数配置
show variables like '%log_bin%';

ここに画像の説明を挿入します

パラメータの説明:

  • log_bin: on は、バイナリ ログがオンであることを意味します。

  • log_bin_basename: 最終的に生成されたバイナリ ログ ファイルは/var/lib/mysqlディレクトリにあります。ファイル名は binlog ですが、ログ ファイルは多数存在する可能性があり、binlog はそのプレフィックスにすぎません。

    • 現在のデータベース サーバーの binlog ログのベース名 (プレフィックス)。特定の binlog ファイル名には、ベース名に基づく番号を追加する必要があります (番号は 000001 から始まり、増加します)。
    • 最初のログ ファイルがいっぱいになるか、ログの形式が変更されると、再度新しいファイルを開いてログを書き込みます。

  • log_bin_index: 現在のサーバーに関連付けられた binlog ファイルを記録する binlog インデックス ファイル。

テスト：

/var/lib/mysql ディレクトリに入って、バイナリ ファイルがあるかどうかを確認します。

#不登录mysql执行
cd /var/lib/mysql

#可以看到二进制日志文件和索引文件
ll

#查看索引文件：里面就记录了当前mysql数据库关联的日志文件有哪些
cat binlog.index

ここに画像の説明を挿入します
ここに画像の説明を挿入します

1.2.2 フォーマット

MySQL サーバーはバイナリ ログを記録するための複数の形式を提供しており、具体的な形式と特性は次のとおりです。

ログ形式 意味
声明 SQL ステートメントに基づくロギングでは SQL ステートメントが記録され、データを変更する SQL がログ ファイルに記録されます。
行 行ベースのログ記録では、各行のデータ変更が記録されます。（デフォルト）
混合 STATEMENT と ROW の 2 つの形式が混在しています。デフォルトでは STATEMENT が使用されますが、特殊な場合には自動的に ROW に切り替わって記録されます。

例: update ステートメントを実行すると、この update ステートメントによって影響を受ける行数は 5 行になります。

  • ステートメント: この更新ステートメントは記録されています
  • ROW: 更新ステートメントの影響を受ける 5 つの行を記録し、各行のデータ内容が変更前と変更後にどのように見えるかを記録します。
#先登录mysql
mysql -uroot -p1234

#通过此系统变量，查看当前mysql的版本中默认的日志格式是那个
show variables like '%binlog_format%';

ここに画像の説明を挿入します

バイナリ ログの形式を設定する必要がある場合は、/etc/my.cnf の binlog_format パラメータを設定するだけです。

vim /etc/my.cnf 

#在这个文件中添加一行内容
binlog_format=STATEMENT

#重新启动mysql服务
systemctl restart mysqld.service

cd /var/lib/mysql

#可以看到此时重新生成了一个日志文件binlog.000005，原先是1~4。
#因为它的二进制日志格式改了，他不会再往原来的二进制日志文件写入了，而是写到一个新的日志文件中。
ll

ここに画像の説明を挿入します
ここに画像の説明を挿入します

このシステム変数を再度確認すると、ログ形式が STATEMENT に変更されていることがわかります。

#先登录mysql
mysql -uroot -p1234

#通过此系统变量，查看当前mysql的版本中默认的日志格式是那个
show variables like '%binlog_format%';

ここに画像の説明を挿入します

1.2.3 ビュー

ログはバイナリ モードで保存され、直接読み取ることができないため、バイナリ ログ クエリ ツール mysqlbinlog を使用して表示する必要があります。具体的な構文は次のとおりです。

#logfilename：二进制文件名
mysqlbinlog [ 参数选项 ] logfilename


参数选项：

	-d 		指定数据库名称，只列出指定的数据库相关操作。
	-o 		忽略掉日志中的前n行命令。
	-v 		将行事件(数据变更)重构为SQL语句
	-vv 	将行事件(数据变更)重构为SQL语句，并输出注释信息

テスト: 次に、これら 2 つのログ形式を設定して、それらの違いを確認してみましょう。

ケース 1: 現在のログ形式は行です

ステップ 1: デモ用の例として、db01 データベースの下の stu テーブルを取り上げます。

客户端1：就是登录进mysql执行的命令

mysql -uroot -p1234

#当前的日志格式是row
show variables like '%binlog_format%';

use db01;

#查看db01数据库下面有哪些表
show tables;

#查看stu表下面有哪些数据
select * from stu;

ここに画像の説明を挿入します
ステップ 2: update ステートメントを実行する

客户端1：

update stu set age = age +1 where id =1;

ここに画像の説明を挿入します

ステップ 3: バイナリ ログ テーブルに記録されている内容を確認する

客户端2：就是没有登录进mysql执行的命令

cd /var/lib/mysql

ll

#因为二进制日志是第一个日志文件写满了之后会开启一个新的日志文件，所以只需要看最后一个日志文件即可。
#二进制文件不能直接查看使用cat显示的是乱码，需要通过mysqlbinlog 指令来查看
#日志里面是以行的格式显示的，所以看不到sql语句，我们还需要使用-v把它重构为sql语句才能看到
#效果：在日志的最后部分可以看到数据执行前后的变化
mysqlbinlog  -v binlog.000004;

ここに画像の説明を挿入します
ログ形式が行になっており、記録されるのは各行のデータ変更と、変更前と変更後の様子であることがわかります。
ここに画像の説明を挿入します

ケース 2: 現在のログ形式は STATEMENT です

ステップ 1: ログ形式を STATEMENT に変更し、/etc/my.cnf の binlog_format パラメータを設定するだけです。

vim /etc/my.cnf 

#在这个文件中添加一行内容
binlog_format=STATEMENT

#重新启动mysql服务
systemctl restart mysqld.service

cd /var/lib/mysql

#可以看到此时重新生成了一个日志文件binlog.000005，原先是1~4。
#因为它的二进制日志格式改了，他不会再往原来的二进制日志文件写入了，而是写到一个新的日志文件中。
ll

ここに画像の説明を挿入します
ここに画像の説明を挿入します

ステップ 2: 前の update ステートメントを再度実行する

mysql -uroot -p1234

use db01;

update stu set age = age +1 where id =1;

ここに画像の説明を挿入します

ステップ 3: 新しく生成されたバイナリ ログ テーブルの内容を再度表示する

#进入到二进制日志文件存放的位置
cd /var/lib/mysql

#可以看到此目录下有这个日志文件
ll

#查看此二进制日志文件
#不需要加-v，因为是STATEMENT它本身记录的就是sql语句
#效果：可以看到此时记录的就是sql语句而不是每一行的数据变化
mysqlbinlog  binlog.000005;

ここに画像の説明を挿入します
ここに画像の説明を挿入します

1.2.4 削除

比較的負荷の高いビジネス システムでは、毎日生成されるバイナリ ログ データは膨大であり、長期間消去されないと、大量のディスク領域を占有します。ログは次の方法でクリアできます。

命令 意味
reset master すべての binlog ログを削除します。削除後、ログ番号は binlog.000001 から再開されます。
purge master logs to 'binlog.*****' ***** 番号より前のすべてのログを削除します
purge master logs before 'yyyy-mm-dd hh24:mi:ss' 「yyyy-mm-dd hh24:mi:ss」の時点より前に生成されたすべてのログを削除します。

mysql 設定ファイルでバイナリ ログの有効期限を設定することもでき、設定後は有効期限が切れるとバイナリ ログが自動的に削除されます。

mysql -uroot -p1234

#查看系统变量，在mysql命令行中执行
#单位是秒，默认过期时间为30天，到期之后会自动删除
show variables like '%binlog_expire_logs_seconds%';

ここに画像の説明を挿入します

テスト：

クライアント 1:

mysql -uroot -p1234

#删除000002之前的日志文件,不包含000002
purge master logs to 'binlog.000002';

ここに画像の説明を挿入します

クライアント 2:

cd /var/lib/mysql

#可以看到二进制日志文件和索引文件
ll

ここに画像の説明を挿入します

1.3 クエリログ

クエリ ログにはクライアントのすべての操作ステートメントが記録されますが、バイナリ ログにはデータをクエリするための SQL ステートメントは含まれません。デフォルトでは、クエリログは有効になっていません。

mysql -uroot -p1234

#检查参数查看开关是否开启
#可以看到默认是关闭的以及日志文件所处位置和文件名
show variables like '%general%';

ここに画像の説明を挿入します

クエリ ログを有効にする必要がある場合は、MySQL 構成ファイル /etc/my.cnf ファイルを変更し、次の内容を追加できます。

vim  /etc/my.cnf 

#该选项用来开启查询日志 ， 可选值 ： 0 或者 1 ； 0 代表关闭， 1 代表开启
general_log=1

#设置日志的文件名 ， 如果没有指定， 默认的文件名为 host_name.log
general_log_file=mysql_query.log

#重启mysql服务
systemctl restart mysqld.service

#查看这个目录下是否会生成此日志文件
cd /var/lib/mysql/

ll

ここに画像の説明を挿入します

ここに画像の説明を挿入します

クエリ ログをオンにすると、mysql_query.log ファイルが MySQL データ ストレージ ディレクトリ、つまり /var/lib/mysql/ ディレクトリに表示されます。その後のクライアントの追加、削除、変更、クエリはすべてこのログ ファイルに記録され、長時間実行すると、ログ ファイルは非常に大きくなります。したがって、このログ ファイルは使用されないので、閉じてかまいません。

テスト:

クライアント 1:


mysql -uroot -p1234

use db01;

#执行查询操作（前提是已经登录）
select * from stu;

#执行更新操作
update stu set age=100 where id=7;

ここに画像の説明を挿入します
クライアント 2:

cd /var/lib/mysql/

#前提是已经进入到了这个目录，并且目录下有这个文件(上面已经配置过了)
#实时刷新此日志文件尾部的内容（tail查看文件尾部，-f表示实时刷新）
tail -f mysql_query.log

すべての DDL および DML 操作がログ テーブルに記録されていることがわかります。

ここに画像の説明を挿入します

1.4 スロークエリログ

スロークエリログは、実行時間がパラメータlong_query_timeの設定値を超え、スキャンレコード数がmin_examined_row_limit以上であるすべてのSQL文のログを記録します。デフォルトでは有効になっていません。long_query_time のデフォルトは 10 秒、最小値は 0、精度は最大マイクロ秒です。

説明する：

  • スロークエリログには、実行効率が比較的低く、実行速度が遅い SQL ステートメントが記録されます。
  • 以前、インデックスのSQLパフォーマンス分析で説明しました。

スロークエリログを有効にする必要がある場合は、MySQL 設定ファイル /etc/my.cnf で次のパラメータを設定する必要があります。

#慢查询日志：1代表开启
slow_query_log=1

#执行时间参数：表示执行时间超过2秒就是慢查询日志，此时慢查询日志文件就会记录这条sql.
long_query_time=2

デフォルトでは、管理ステートメントはログに記録されず、検索にインデックスを使用しないクエリもログに記録されません。この動作は、以下で説明するように、log_slow_admin_statements および log_queries_not_using_indexes を使用して変更できます。

説明する：

  • vim /etc/my.cnf 構成ファイルでこれら 2 つのパラメーターを構成することにより、デフォルトの動作を変更できます。
  • log_slow_admin_statements =1 が追加された場合、これは、比較的遅い管理ステートメントを実行すると、それらのステートメントがスロー クエリ ログにも記録されることを意味します。
  • log_queries_not_using_indexes = 1 が追加された場合: 特定の SQL ステートメントがインデックスを使用せず、実行速度の低下を引き起こした場合、スロー クエリ ログにも記録されることを意味します。
  • 低速クエリ ログを通じて、実行効率が低い SQL ステートメントを特定し、そのような SQL ステートメントを最適化できます。
#记录执行较慢的管理语句
log_slow_admin_statements =1

#记录执行较慢的未使用索引的语句
log_queries_not_using_indexes = 1

上記のパラメータをすべて設定したら、有効にするために MySQL サーバーを再起動する必要があります。

テスト：

クライアント 1:

mysql -uroot -p1234

#db01数据库下有tb_sku表，存放了1000万条记录
#电脑太卡，所以我没有创建tb_sku表,这里不在演示，只显示最终结果
use db01;

#不会记录
select * from tb_user limit 0,10; -- 这条SQL执行效率比较高, 执行耗时 0.01sec

#前面学习过SQL优化，分页查询越向后效率越低，此时超过2秒，会记录在慢查询日志中
select * from tb_user limit 1000000,10; -- 由于tb_sku表中, 预先存入了1000w的记录, count一次,耗时4.71sec（秒）

クライアント 2:

#配置慢查询日志
vim /etc/my.cnf 

#配置的内容
slow_query_log=1

long_query_time=2

# 重启Mysql服务器
systemctl restart mysqld

# 进入到此目录，发现会有一个后缀是-slow.log的日志文件
cd /var/lib/mysql/

ll

#实时刷新文件尾部的位置发现：
#记录了什么时间哪一个用户在哪一个主机上执行了什么样的sql语句
tail -f mysql8-slow.log

ここに画像の説明を挿入します
ここに画像の説明を挿入します
ここに画像の説明を挿入します

2. マスター/スレーブ レプリケーション

2.1 概要

マスター/スレーブ レプリケーションとは、バイナリ ログを通じてマスター データベースの DDL および DML 操作をスレーブ データベース サーバーに送信し、これらのログをスレーブ データベースで再実行 (REDO とも呼ばれます) することを指します。これにより、スレーブ データベースのデータがとマスター データベースは維持されます。

MySQL は、1 つのマスター データベースを複数のスレーブ データベースに同時にレプリケートすることをサポートしており、スレーブ データベースは他のスレーブ サーバーのマスター データベースとして機能してチェーン レプリケーションを実現することもできます。

ここに画像の説明を挿入します

MySQL レプリケーションの利点には主に次の 3 つの側面が含まれます。

  • メインライブラリに問題が発生した場合、すぐにスレーブライブラリに切り替えてサービスを提供できます。
  • 読み書きの分離を実現し、メインライブラリのアクセスプレッシャーを軽減します。
    • マスター データベースを追加、削除、変更し、スレーブ データベースをクエリします。
  • バックアップ中のマスター データベース サービスへの影響を避けるために、バックアップはスレーブ データベースで実行できます。
    • データをバックアップする場合、バックアップ データが不完全になるのを防ぐためにグローバル ロックが追加されます。この時点では、データベースは読み取り専用状態になり、他のクライアントはクエリのみを実行でき、追加、削除、変更はできません。
    • マスター/スレーブ レプリケーションを使用すると、スレーブ データベースをロックするだけでスレーブ データベースのバックアップを実行でき、マスター データベースでは追加、削除、変更などの操作を実行できます。スレーブ データベースにグローバル ロックを追加した後もクエリは実行できますが、スレーブ データベースはバックアップ期間中にマスター データベースから同期されたバイナリ ログを実行できないため、データ バックアップ期間中に一定のデータ遅延が発生する可能性があります。
    • 解決策: バックアップにグローバル ロックを追加する代わりに、単一トランザクション パラメータを使用して、データの一貫したバックアップを確保できます。----- 詳細については、グローバル ロックを参照してください。

2.2 原則

MySQL のマスター/スレーブ レプリケーションの中核はバイナリ ログであり、具体的なプロセスは次のとおりです。

ここに画像の説明を挿入します

上の図から、コピーは 3 つのステップに分かれています。

  1. Master データベースがトランザクションをコミットすると、データの変更がバイナリ ログ ファイル Binlog に記録されます。

  2. スレーブ ライブラリは、メイン ライブラリのバイナリ ログ ファイル Binlog を読み取り、スレーブ ライブラリに書き込みます中继日志 Relay Log。

    • スレーブ ライブラリの IOthread スレッド: マスター データベースに接続するリクエストを開始し、マスター データベースの Binlog ログを読み取ります。読み取ってスレーブ ライブラリに戻った後、このスレッドは Binlog ログをスレーブライブラリ自体（リレーログ）。

  3. スレーブはデータベースからリレー ログ内のイベントを再実行し、変更は自身のデータを反映します。

    • スレーブ ライブラリの SQLthread スレッド: リレー ログのデータを読み取り、リレー ログに記録されたデータの変更を自身のデータベースのデータ変更に反映することで、マスターとスレーブのデータの一貫性が保証されます。

例: メイン ライブラリが挿入ステートメントを実行した後、それをバイナリ ログに書き込み、IOthread スレッドによって読み取られてリレー ログに書き込まれます。その後、SQLthread スレッドはリレーの読み取り時に挿入ステートメントを読み取ります。その後、下に降りてスレーブ ライブラリでこの挿入を実行すると、マスターとスレーブのデータの一貫性が保証されます。

2.3 セットアップ

2.3.1 環境の準備

ここに画像の説明を挿入します

2台のサーバを用意したら、上記2台のサーバにMySQLをインストールし、基本的な初期設定（インストール、パスワード設定など）を完了します（注意要关闭防火墙）。で：

  • 192.168.10.200メインサーバーマスターとして

    • ホスト名：マスター

  • 192.168.10.201奴隷として

    • ホスト名: スレーブ
      ここに画像の説明を挿入します

注意事项：

  • 最初に構成された IP アドレスは、仮想マシンに構成されたドメイン名解決と同じネットワーク セグメント上にある必要があります。最後の IP アドレスのみが異なることができます。
    ここに画像の説明を挿入します
  • 仮想マシンを再起動してもens33ネットワークカードが表示されない場合は、ネットワークサービスを再起動する必要がありますが、当然、サービス起動時にエラーが報告される場合があり、NetworkMangerサービスを終了する必要があります。

    • ifconfig 例外では ens33 が表示されません:
      ここに画像の説明を挿入します

    • Ifconfig では通常、ens33 が表示されます。
      ここに画像の説明を挿入します

#重启网络服务，可能会报错
service network restart

#如果报错：可能是和 NetworkManager 服务有冲突
#NetworkManager 是一个为系统提供检测和配置功能以便自动连接到网络的程序。包含一个守护程序、一个命令行界面（nmcli）和一个基于 curses 的界面（nmtui）。

#解决：直接关闭 NetworkManger 服务就好了，并且禁止开机启动，之后在重启网络服务
#关闭NetworkManger 服务
service NetworkManager stop

#禁止开机启动
chkconfig NetworkManager off

#此时再次启动网络服务就会成功了
service network restart

最後に、2 つの mysql サーバーの実行ステータスを確認します。

systemctl status mysqld

ここに画像の説明を挿入します
ここに画像の説明を挿入します

2.3.2 主なライブラリ構成

1. 設定ファイルを変更する vim /etc/my.cnf

#mysql 服务ID，保证整个集群环境中唯一，取值范围：1 – 232-1，默认为1
server-id=1

#是否只读,1 代表只读, 0 代表读写
read-only=0

#以下2个不需要配置，表示创建的所有数据库都需要进行同步
#忽略的数据, 指不需要同步的数据库
#binlog-ignore-db=mysql

#指定同步的数据库
#binlog-do-db=db01

ここに画像の説明を挿入します

2. MySQL サーバーを再起動します。

#如果没有报错代表配置文件中的配置成功
systemctl restart mysqld

ここに画像の説明を挿入します

3.登录mysqlリモート接続アカウントを作成し、マスター/スレーブ レプリケーション権限を付与します。

説明する

  • 'itcast'@'%': はitcastユーザー名です。@'% は、このユーザーが任意のホスト上の現在のサーバーにアクセスできることを意味します
  • パスワードは:Root@123456
#需要先登录mysql
mysql -uroot -p1234

#创建itcast用户，并设置密码，该用户可在任意主机连接该MySQL服务
#作用：在从库当中连接主库时的账号和密码。
CREATE USER 'itcast'@'%' IDENTIFIED WITH mysql_native_password BY 'Root@123456';


#为 'itcast'@'%' 用户分配主从复制权限
GRANT REPLICATION SLAVE ON *.* TO 'itcast'@'%';

ここに画像の説明を挿入します

4. コマンドを使用してバイナリ ログ座標を表示する

show master status ;

ここに画像の説明を挿入します

フィールドの意味の説明:

  • file: どのログ ファイルからログ ファイルのプッシュを開始するか (そのログ ファイルに書き込みます)
  • Position: ログのプッシュを開始する位置
  • binlog_ignore_db: 同期する必要のないデータベースを指定します
  • 主库配置完后就不要在执行DML增删改以及DDL语句了。

2.3.3 スレーブライブラリの構成

1. 設定ファイルを変更するvim /etc/my.cnf

#mysql 服务ID，保证整个集群环境中唯一，取值范围：1 – 2^32-1，和主库不一样即可
server-id=2


#是否只读,1 代表只读, 0 代表读写
#从库只需要做查询操作不需要做修改操作，所以设置为1也可以。
#这个选项仅仅代表是普通用户只读，如果这个用户具有超级管理员super的权限，那么他也是可以进行读写的。
read-only=1

#如果想要禁用超级管理员的读写功能，让它也变为只有读的功能，可以设置以下参数
super-read-only=1

ここに画像の説明を挿入します

2. MySQL サービスを再起動します。

systemctl restart mysqld

ここに画像の説明を挿入します

3. 登录mysql、メインライブラリ構成を設定します

現在、メイン ライブラリとスレーブ ライブラリには関係がなく、関連付けられていないため、次に、メイン ライブラリの関連する構成をスレーブ ライブラリに設定する必要があります。

  • SOURCE_HOST='192.168.200.200': 元のホスト アドレス (メイン ライブラリの IP)
  • SOURCE_USER='itcast': この IP アドレスに対応する mysql に接続します。その後、私のユーザー名は何ですか?
  • SOURCE_PASSWORD='Root@123456': パスワードは何ですか?
  • SOURCE_LOG_FILE='binlog.000004': どのバイナリ ログ ファイルから同期を開始するか
  • SOURCE_LOG_POS=663: 同期を開始するこのログ ファイル内の位置を示します。
mysql -uroot -p1234

CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.10.200', SOURCE_USER='itcast',SOURCE_PASSWORD='Root@123456', SOURCE_LOG_FILE='binlog.000012',SOURCE_LOG_POS=663;

ここに画像の説明を挿入します

上記は 8.0.23 の構文です。mysql が8.0.23より前のバージョンの場合は、次の SQL を実行します。

CHANGE MASTER TO MASTER_HOST='192.168.10.201', MASTER_USER='itcast',MASTER_PASSWORD='Root@123456', MASTER_LOG_FILE='binlog.000012',MASTER_LOG_POS=663;

2 つのバージョンの違いはパラメータ名が異なることです。現在使用されているバージョン 8.0.26 は以前の構文と互換性があるため、どちらを実行しても問題ありません。

パラメータ名 意味 8.0.23より前
ソース_ホスト メインライブラリのIPアドレス MASTER_HOST
ソース_ユーザー メインライブラリに接続するためのユーザー名 MASTER_USER
SOURCE_PASSWORD メインライブラリに接続するためのパスワード マスターパスワード
SOURCE_LOG_FILE binlog ログ ファイル名 MASTER_LOG_FILE
SOURCE_LOG_POS binlog ログ ファイルの場所 MASTER_LOG_POS

4. 同期操作を有効にする

start replica ; #8.0.22之后

start slave ; #8.0.22之前

ここに画像の説明を挿入します

5. マスタとスレーブの同期状態を確認する

show replica status ; #8.0.22之后
#表中的数据比较大展示出来的效果比较混乱，可以加上\G把每一列数据转化为每一行显示。
show replica status\G; 

show slave status ; #8.0.22之前

効果: 次の 2 つのオプションが [はい] である限り、マスター/スレーブ レプリケーションが正常であることを意味し、IO-Running は io スレッドのグループが正常に実行されているかどうかを意味し、SQL-Running は SQL スレッドのグループが実行されているかどうかを意味します。通常は。

エラー状況: クローン仮想マシンの場合、mysql の uuid 値は同じです。スレーブ仮想マシンの mysql サーバーの uuid 値を変更する必要があります。メイン ライブラリと同じにすることはできません。
ここに画像の説明を挿入します

解決する：

#不需要登录mysql
#修改此文件中的uuid值，随便修改一个字符
vim  /var/lib/mysql/auto.cnf

#重启mysql服务
systemctl restart mysqld

ここに画像の説明を挿入します

ここに画像の説明を挿入します

マスターとスレーブの同期ステータスを再度クエリします。今回は両方とも Yes です (スレーブ データベースから実行されることに注意してください)。

#登录进mysql后执行，可以开启多个会话窗口这样就不需要多次登陆了
show replica status\G;

ここに画像の説明を挿入します

2.3.4 テスト

まず、現時点でのデータベースのステータスをクエリします。

show databases;

ここに画像の説明を挿入します
ここに画像の説明を挿入します

1.メインデータベース192.168.10.200 にデータベースとテーブルを作成し、データを挿入します。

create database db02;

use db02;

create table tb_user(

	id int(11) primary key not null auto_increment,
	name varchar(50) not null,
	sex varchar(1)
	
)engine=innodb default charset=utf8mb4;

insert into tb_user(id,name,sex) values(null,'Tom', '1'),(null,'Trigger','0'),(null,'Dawn','1');

ここに画像の説明を挿入します

2.スレーブ データベース192.168.10.201のデータをクエリして、マスターとスレーブが同期されているかどうかを確認します。

show datables;

use db02;

show tables;

select * from tb_user;

ここに画像の説明を挿入します

知らせ：

  • 先ほど示したマスター/スレーブ レプリケーションは、バイナリ ログの現在位置から後方へのマスター/スレーブ レプリケーションです。以前のデータをスレーブ データベースに同期したい場合は、この時点で、まずデータを SQL にエクスポートします。スクリプトを作成し、スレーブライブラリで SQL スクリプトを実行し、メインライブラリとスレーブライブラリの初期データが一致していることを確認してから、現在位置から同期します。

2.4 概要

ここに画像の説明を挿入します

おすすめ

転載: blog.csdn.net/aa35434/article/details/133524177
おすすめ
TIOBE 5 月リスト: Fortran がトップ 10 に「復活」
GCC 14.1 发布
ランキング
Linuxの一般的なコマンドの緊急対応
FPGAの設計者は、5つの基本的なスキルです
Javaの研究では、2019年6月12日ノート
Golang底层原理剖析之内存逃逸
VIM - Viは、プログラマーのテキストエディタを改善しました
魔法書（MagicTable）入門チュートリアルは、CADの一括転送複数のテーブルExcelをExcelを回し--CAD
mockitoとの望ましくないモック
EVE-NG MPLS L2VPN BGP pw -- スタティック ルート、スタティック mpls lsp
抵抗性タッチスクリーンドライバ（II）
PHP 安装扩展 Api Version 和扩展extensions路径不匹配的问题
アーカイブ
もっと
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)
2024-05-03(8)
2024-05-02(0)
2024-05-01(4)
2024-04-30(35)
2024-04-29(5)

コードワールド

© 2018 codetd.com