마스터-슬레이브 복제 문제로 인한 아키텍처 최적화에 대한 생각

문제가 있습니다

마스터-슬레이브 복제 아키텍처는 1032 오류, 1062 오류 등 복제 정체 문제가 많습니다. 그 중 마스터 데이터베이스 성공 후 1032 오류가 발생합니다. 슬레이브 데이터베이스의 업데이트 또는 업데이트를 실행하는 중, 슬레이브 라이브러리에서 이 레코드를 찾을 수 없는 것으로 나타났습니다. 1062 오류는 메인 라이브러리 이후 슬레이브 라이브러리를 실행했을 때 발생한 기본 키 충돌로 인해 발생했습니다. 삽입이 완료되어 삽입에 성공하지 못했습니다. 이러한 문제는 오류 및 이전 복사본 데이터 확인을 건너뛰면 해결될 수 있지만 이러한 문제의 직접적인 원인은 마스터-슬레이브 데이터베이스 데이터의 불일치입니다. 이러한 불일치는 논리적 복제 자체에서 발생할 수 있는 데이터 불일치 외에도 비즈니스 측이나 개발자가 규정을 위반하여 대기 데이터베이스에 대한 추가, 삭제, 수정 작업을 직접 수행하는 경우에도 발생합니다.

마스터-슬레이브 복제 아키텍처에서 마스터-슬레이브 라이브러리는 VIP 바인딩을 구현하여 해당 라이브러리를 마스터 라이브러리로 지정하여 읽기 및 쓰기 기능을 제공하며, 문제 발생 시 슬레이브 라이브러리가 백업 역할을 합니다. 마스터 라이브러리에서 VIP는 슬레이브 라이브러리로 전환됩니다. 슬레이브 라이브러리는 읽기 및 쓰기를 제공합니다. 그렇지 않으면 슬레이브 라이브러리는 백업일 뿐입니다. 일반적인 상황에서는 개발자가 고정 IP를 통해 슬레이브 데이터베이스에 직접 로그인하는 것을 허용하지 않지만, 실제 작업에서는 이를 피하기 어려운 경우가 많습니다. 그렇다면 기술적 관점에서 개발자가 슬레이브 데이터베이스에서 작업하는 것을 방지하는 방법은 무엇일까요? 고가용성 아키텍처의 정상적인 작동 및 장애 조치에 영향을 주지 않고 이를 방지하려면 어떻게 해야 합니까?

2. 아키텍처 구성 최적화

(1) 직접적인 해결 방법

위의 문제를 해결하는 직접적인 방법은 고려 아키텍처 구성이 최적화되었습니다. 즉, 슬레이브 라이브러리의 읽기-쓰기 상태가 읽기 전용 상태로 구성됩니다.

MySQL 공식 홈페이지에는 읽기 전용에 대해 다음과 같은 설명이 있습니다.

1.Whenthe read_only system variable is enabled, the server permits no client updatesexcept from users who have the SUPER privilege. 
只读情况下，super权限可读写。
2.Updates performed by slave threads, if theserver is a replication slave. In replication setups, 
it can be useful toenable read_only on slave servers to ensure that slaves accept updates only from themaster server and not from clients.
不影响主从复制线程的读写。

읽기 전용을 켠 후 슈퍼 권한 계정 및 복제 스레드 등을 제외하고 비즈니스 측 개발자 및 기타 백업 서버에 로그인하더라도 인력은 영향을 받지 않습니다. 데이터베이스는 대기 데이터베이스 데이터도 작동할 수 없습니다.

MySQL [db1]> show global variables like'read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON   |
+---------------+-------+
1 row in set (0.00 sec)
 
MySQL [test]> insert child values('1','12');
ERROR 1290 (HY000): The MySQL server is running withthe --read-only option so it cannot execute thisstatement

(2) 읽기 전용으로 설정한 후 완벽한 Failover를 수행하려면 어떻게 해야 하나요?

슬레이브 라이브러리에서 읽기 전용으로 불법 운영을 피할 수 있지만, 문제는 메인 라이브러리에 문제가 생기면 VIP가 슬레이브 라이브러리로 전환해야 하는데, 이때 슬레이브 라이브러리에서 읽기 전용을 수행하면 데이터베이스가 외부 서비스를 사용할 수 없게 되므로 전환 시 슬레이브 라이브러리의 읽기 전용 기능을 취소하고 메인 라이브러리의 읽기 전용 기능을 설정해야 합니다. .

Keepalived + MySQL 이중 마스터(마스터-슬레이브) 아키텍처를 예로 들면, 정상 작동 중에 VIP는 Master1에 있고 Master1은 읽기-쓰기 상태이고 Master2는 읽기 전용 상태입니다. Master1에 문제가 발생하면 VIP는 자동으로 Master2로 전환됩니다. 전환하기 전에 두 단계를 완료해야 합니다. 1. Master1을 읽기 전용으로 설정합니다. 2. Master2의 읽기 전용을 취소합니다.

3. 자동화된 구현 아이디어

마스터-슬레이브 아키텍처의 경우 장애 조치를 수동으로 수행해야 하므로 위의 두 단계도 수동으로 수행할 수 있지만 Keepalived는 수행할 수 없습니다. +MySQL 듀얼 마스터(마스터-슬레이브 아키텍처에서는 자동 오류 모니터링 및 자동 VIP 전환이 구현되었습니다. 자동화를 달성하려면 위의 두 단계도 스크립트에 포함되어야 합니다.

주로 자동 모니터링 및 전환 스크립트에는 데이터베이스에 대한 읽기 전용을 켜고 끄는 기능을 포함해야 합니다. 주로 "set global read_only=ON" 및 "set globalread_only=OFF" 명령문을 작성합니다. 동시에, 상태를 설정하기 전에 먼저 기존 상태를 확인하십시오. 쉘은 읽기 및 쓰기 상태를 확인하기 위해 "'read_only';"라는 명령문을 호출합니다. 읽기 전용 매개변수를 필수 상태로 설정하십시오. 이러한 상태 설정의 트리거 사용자 정의는 오류가 감지되고 전환이 수행되기 전입니다.

위 아이디어는 이제 자동으로 변환되어 개인 테스트에 성공하여 아이디어가 맞다는 것을 알 수 있습니다.

위 내용은 마스터-슬레이브 복제 문제로 인한 아키텍처 최적화 사고 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 주목해주세요!