1. 로그
1.1 오류 로그
에러 로그는 MySQL에서 가장 중요한 로그 중 하나로서, 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 두 가지 형식을 혼합하여 사용하며, 기본적으로 STATEMENT를 사용하며, 특별한 경우에는 자동으로 ROW로 전환하여 기록합니다. |
예: update 문을 실행하면 이 update 문에 의해 영향을 받는 행 수는 5개 행입니다.
- STATEMENT: 이 업데이트 문은 기록됩니다.
- 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语句，并输出注释信息
테스트: 다음으로 이 두 가지 로그 형식을 설정하고 두 형식의 차이점이 무엇인지 살펴보겠습니다.
사례 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단계: 업데이트 문 실행
客户端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;
로그 형식이 행(Row)으로 기록되는 것을 볼 수 있으며, 기록되는 내용은 각 행의 데이터 변경, 변경 전과 변경 후의 모습입니다.
사례 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단계: 이전 업데이트 문을 다시 실행합니다.
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 삭제
비교적 사용량이 많은 비즈니스 시스템의 경우 매일 생성되는 binlog 데이터는 엄청나기 때문에 오랫동안 삭제하지 않으면 많은 디스크 공간을 차지하게 됩니다. 로그는 다음과 같은 방법으로 지울 수 있습니다.
| 지침 | 의미 |
|---|---|
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구성 파일에서 이 두 매개변수를 구성하면 기본 동작을 변경할 수 있습니다 .- log_slow_admin_statements =1이 추가되면 상대적으로 느린 관리 명령문을 실행할 때 느린 쿼리 로그에도 기록된다는 의미입니다.
- log_queries_not_using_indexes = 1이 추가되면 특정 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은 하나의 마스터 데이터베이스를 지원하여 여러 슬레이브 데이터베이스에 동시에 복제할 수 있으며, 슬레이브 데이터베이스는 다른 슬레이브 서버의 마스터 데이터베이스 역할을 하여 체인 복제를 수행할 수도 있습니다.
MySQL 복제의 장점은 주로 다음 세 가지 측면을 포함합니다.
- 메인 라이브러리에 문제가 있을 경우 빠르게 슬레이브 라이브러리로 전환하여 서비스를 제공할 수 있습니다.
- 읽기와 쓰기의 분리를 실현하고 메인 라이브러리의 접근 부담을 줄입니다.
- 마스터 데이터베이스를 추가, 삭제, 수정하고, 슬레이브 데이터베이스를 쿼리합니다.
- 백업 중에 마스터 데이터베이스 서비스에 영향을 주지 않도록 슬레이브 데이터베이스에서 백업을 수행할 수 있습니다.
- 데이터 백업 시 백업 데이터가 불완전한 것을 방지하기 위해 글로벌 잠금(Global Lock)을 추가하는데, 이때 데이터베이스는 읽기 전용 상태로, 다른 클라이언트는 쿼리만 가능하고 추가, 삭제, 수정은 불가능하다.
- 마스터-슬레이브 복제를 사용하면 슬레이브 데이터베이스를 잠그는 것만으로 슬레이브 데이터베이스에서 백업을 수행할 수 있으며, 마스터 데이터베이스는 추가, 삭제, 수정 등의 작업을 계속 수행할 수 있습니다. 슬레이브 데이터베이스에 글로벌 잠금을 추가한 후에도 쿼리는 가능하지만, 백업 기간 동안 슬레이브 데이터베이스는 마스터 데이터베이스에서 동기화된 바이너리 로그를 실행할 수 없기 때문에 데이터 백업 기간 동안 특정 데이터 지연이 발생할 수 있습니다.
- 해결 방법: 백업용 전역 잠금을 추가하는 대신 단일 트랜잭션 매개변수를 사용하여 데이터의 일관된 백업을 보장할 수 있습니다. ------ 자세한 내용은 전역 잠금을 참조하세요.
2.2 원리
MySQL 마스터-슬레이브 복제의 핵심은 바이너리 로그 이며 구체적인 프로세스는 다음과 같습니다.
위 그림에서 복사는 세 단계로 나누어집니다.
-
마스터 데이터베이스가 트랜잭션을 커밋하면 바이너리 로그 파일 Binlog에 데이터 변경 사항이 기록됩니다.
-
슬레이브 라이브러리는 메인 라이브러리의 바이너리 로그 파일 Binlog를 읽어 슬레이브 라이브러리에 씁니다
中继日志 Relay Log.- 슬레이브 라이브러리의 IOthread 스레드: 마스터 데이터베이스에 연결하기 위한 요청을 시작한 다음 마스터 데이터베이스의 Binlog 로그를 읽습니다. 슬레이브 라이브러리를 읽고 반환한 후 이 스레드는 Binlog 로그를 다음의 로그에 기록합니다. 슬레이브 라이브러리 자체(릴레이 로그)
-
슬레이브는 데이터베이스의 릴레이 로그에 있는 이벤트를 다시 실행하며 변경 사항은 자체 데이터를 반영합니다.
- 슬레이브 라이브러리의 SQLthread 스레드: 릴레이 로그의 데이터를 읽은 후 릴레이 로그에 기록된 데이터 변경 사항을 자체 데이터베이스의 데이터 변경 사항에 반영하여 마스터-슬레이브 데이터의 일관성을 보장합니다.
예를 들어, 메인 라이브러리가 insert 문을 실행한 후 이를 바이너리 로그에 기록한 다음 IOthread 스레드에서 읽은 다음 릴레이 로그에 기록하면 SQLthread 스레드는 릴레이를 읽을 때 insert 문을 읽습니다. 그런 다음 아래로 내려와 슬레이브 라이브러리에서 이 삽입을 실행하면 마스터-슬레이브 데이터의 일관성이 보장됩니다.
2.3 설정
2.3.1 환경 준비
두 대의 서버를 준비한 후 위에서 언급한 두 대의 서버에 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
마지막으로 두 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;
두 버전의 차이점은 매개 변수 이름이 다르다는 것입니다. 현재 사용되는 버전 8.0.26은 이전 구문과 호환되므로 둘 중 하나를 실행할 수 있습니다.
| 매개변수 이름 | 의미 | 8.0.23 이전 |
|---|---|---|
| SOURCE_HOST | 기본 라이브러리 IP 주소 | MASTER_HOST |
| SOURCE_USER | 메인 라이브러리에 연결하기 위한 사용자 이름 | MASTER_USER |
| SOURCE_PASSWORD | 메인 라이브러리에 연결하기 위한 비밀번호 | MASTER_PASSWORD |
| 소스_LOG_FILE | binlog 로그 파일 이름 | MASTER_LOG_FILE |
| 소스_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之前
효과 : 다음 두 옵션이 yes인 경우 마스터-슬레이브 복제가 정상임을 의미하고, 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 요약
