MySQL이 마스터-슬레이브 복제 프로세스를 구현하는 방법에 대한 자세한 예(그림)

이 글은 주로 MySQL 마스터-슬레이브 복제 구현 과정을 자세히 소개하며, 관심 있는 친구들은 참고할 수 있습니다.

1. 마스터-슬레이브 복제란 무엇입니까

마스터 데이터베이스를 DDL에 통합합니다. DML 작업은 바이너리 로그(BINLOG)를 통해 슬레이브 데이터베이스로 전송된 후 이러한 로그가 다시 실행(redone)되어 슬레이브 데이터베이스의 데이터가 마스터 데이터베이스와 일치하게 됩니다.

2. 마스터-슬레이브 복제의 역할

1. 마스터 데이터베이스에 문제가 있을 경우 슬레이브 데이터베이스로 전환할 수 있습니다.

2. 데이터베이스 수준에서 읽기 및 쓰기 분리가 가능합니다.

3. 복제 프로세스

바이너리 로그입니다. master 데이터베이스

릴레이 로그 : 서버의 릴레이 로그

1단계: master는 각 트랜잭션 업데이트 데이터가 완료되기 전에 작업 레코드를 binlog 파일에 직렬로 기록합니다.

2단계: salve는 I/O 스레드를 엽니다. 이 스레드는 마스터에서 일반 연결을 열고 주요 작업은 binlog 덤프 프로세스입니다. 읽기 진행 상황이 마스터를 따라잡으면 절전 상태로 들어가고 마스터가 새 이벤트를 생성할 때까지 기다립니다. I/O 스레드의 궁극적인 목적은 이러한 이벤트를 릴레이 로그에 기록하는 것입니다.

3단계: SQL 스레드는 릴레이 로그를 읽고 로그의 SQL 이벤트를 순차적으로 실행하여 기본 데이터베이스의 데이터와 일치하게 합니다.

4. 마스터-슬레이브 복제의 특정 작업

같은 창에서 서로 다른 경로에 두 개의 msyql 인스턴스를 설치했습니다. 내 버전은 일관성이 없지만 마스터와 슬레이브 사이에 설치된 mysql 버전은 일관성을 유지하는 것이 좋습니다.

1. 마스터 및 슬레이브 데이터베이스의 구성 파일 my.ini를 각각 수정합니다.

master

3306은 mysql의 기본 포트 번호입니다. 여기서는 마스터 인스턴스를 지정하는 데 사용됩니다. 고유 ID는 다른 mysql 인스턴스에서만 중복되지 않아야 합니다. binlog-do-db는 바이너리 로그를 여는 데 사용되는 데이터베이스를 지정합니다. 파일.

salve

마스터 및 슬레이브 데이터베이스는 나중에 동일한 컴퓨터에서 실행되므로 포트를 다른 포트로 설정해야 합니다. 여기서는 3307

replicate-do-db의 이름입니다. 동기화가 필요한 데이터베이스는 마스터의 구성과 일치합니다.

2. 마스터 복제를 위해 특별히 계정을 만듭니다: weidai/123456

이 새로 추가된 계정은 mysql.user 테이블에서 쿼리할 수 있습니다:

이것은 당시 첫 번째 작업입니다. 여기서 본 계정 생성은 완료되었으나 실제 복사를 해보니 복사에 성공하지 못한 것으로 확인되었으며, 오류 해결 결과 마스터에서 생성한 빈롱에는 문제가 없는 것으로 확인되었으며, 그런 다음 슬레이브 상태를 확인합니다.

마지막에 다음과 같은 오류가 있습니다.

Weeidai 계정을 사용하면 마스터에 연결할 수 없으므로 마스터의 binlog를 가져오면 안 됩니다. , 릴레이 로그를 생성할 수 없게 됩니다.

계정과 비밀번호를 반복해서 확인했는데 문제가 없었습니다. 그러다가 관련 정보를 검색해 보니 마스터가 새 사용자를 생성할 때 누락된 단계가 있었기 때문이었습니다.

새 사용자를 설정하거나 변경한 후. 비밀번호를 사용하려면 플러시 권한을 사용하여 MySQL 관련 테이블을 새로 고쳐야 합니다. 그렇지 않으면 액세스가 거부됩니다. 이것이 이전 오류가 발생한 이유입니다. 또 다른 방법은 mysql 서버를 다시 시작하여 새 설정을 적용하는 것입니다.

3. 이때 기본 데이터베이스에서 데이터의 위치를 ​​가져옵니다. 그러나 이 상태 값을 가져오기 전에 주로 데이터의 시작 위치를 복사하는 데 사용됩니다. 더 이상 데이터를 수정할 수 없습니다. 따라서 먼저 읽기 잠금을 유효하게 설정해야 합니다

4. 메인 라이브러리는 데이터 백업을 수행하는데, 여기서는 소개하지 않겠습니다. 백업이 완료된 후에는 읽기 잠금이 해제되어 메인 라이브러리를 수행할 수 있습니다.

5 슬레이브 데이터베이스를 시작하고 방금 백업한 데이터를 복원합니다. 이때 백업 시점의 마스터 데이터베이스와 슬레이브 데이터베이스의 데이터는 일치합니다.

6. 데이터베이스의 복제 동작 관련 구성

7. 이때 구성이 완료되었지만 아직 슬레이브 데이터베이스를 동기화할 수 없어 슬레이브 스레드를 시작해야 합니다

8. 마스터에서 테이블 생성 그리고 새로 추가된 데이터를 슬레이브에서 관찰:

마스터에서 수행한 작업이 슬레이브에 반영될 수 있음을 알 수 있습니다. 주인의 거울.

5. 마스터-슬레이브 동기화 상태 해석

슬레이브에서 명령을 사용하여 확인하세요.

레이아웃이 너무 보기 흉해서 다음과 같이 구성했습니다.

Slave_IO_STATE:Waiting for master to send event
Master_host:127.0.0.1
Master_user:weidai
Master_port:3306
connnect_retry:60
Master_log_file:mysql-bin.000005
Read_Master_log_pos:1662
Relay_log_file:AE6Z*****-relay-bin.000002
Relay_log_pos:1415
Slave_IO_Running:yes
Slave_SQL_Running:yes

------ ----- ------------------- -- 화려한 분할선----------------------------------------------- ---

Slave_IO_Running:yes

Slave_SQL_Running:yes

이 두 스레드는 앞에서 언급한 것처럼 복제 프로세스에 참여하는 슬레이브의 매우 중요한 두 스레드입니다. YES는 정상, NO는 비정상을 의미합니다.

Slave_IO 스레드는 주로 마스터의 binlong 로그 내용을 슬레이브의 릴레이 로그(Relay_log)에 복사합니다. 일반적으로 문제가 발생할 가능성은 대부분 권한이나 네트워크 문제로 인해 발생하므로 연결이 불가능합니다. 주인. . 앞서 언급한 오류와 같습니다.

Slave_SQL 스레드는 릴레이 로그의 SQL 실행을 담당하며 오류 확률이 상대적으로 높습니다. 누군가가 슬레이브 데이터베이스에 일부 레코드를 수동으로 삽입하면 마스터-슬레이브 동기화 중에 기본 키 충돌이 발생합니다.

Slave_IO_STATE: 마스터가 이벤트를 전송하기를 기다리는 중

이 상태는 릴레이 로그 동기화가 완료되었으며 마스터에 의해 새 이벤트가 생성되기를 기다리고 있음을 나타냅니다.

위 내용은 MySQL이 마스터-슬레이브 복제 프로세스를 구현하는 방법에 대한 자세한 예(그림)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!