MySQL 내부 복제 기능은 두 대 이상의 서버 간에 설정되며, 이들 간의 마스터-슬레이브 관계를 설정하여 이루어집니다. 그 중 하나는 마스터 서버 역할을 하고 다른 하나는 슬레이브 서버 역할을 합니다. 두 대의 서버를 구성하여 하나는 마스터로, 다른 하나는 슬레이브로 만드는 방법을 자세히 설명하겠습니다. 그리고 그 사이를 전환하는 과정을 설명합니다. MySQL 버전 3.23.23에서 구성 설정 과정을 진행하였고, 이번 버전에서도 테스트를 진행하였습니다. MySQL 개발자는 최신 버전을 사용하는 것이 가장 좋으며 마스터 서버와 슬레이브 서버 모두 동일한 버전을 사용하는 것이 좋습니다. 동시에 MySQL 버전 3.23은 아직 베타 버전이므로 이 버전은 이전 버전과 호환되지 않을 수 있습니다. 그래서 실제 웹사이트에서는 아직 이 버전을 사용하지 않고 있습니다. 내결함성을 갖는 한 가지 이점은 쿼리를 중단하지 않고 서버를 업그레이드할 수 있다는 것입니다.
1단계: 기본 서버 구성
이 기사의 나머지 부분에서는 두 개의 서버를 지정하겠습니다. A(IP는 10.1.1.1)가 메인 서버(호스트라고 함) 역할을 합니다. B(IP는 10.1.1.2)가 백업 서버(백업 서버라고 함) 역할을 합니다.
MySQL의 복제 기능 구현 과정은 다음과 같습니다. 대기 머신(B)이 호스트 머신(A)에 연결한 후 호스트 머신의 바이너리 업데이트 로그를 읽고 변경 사항을 머신에 병합합니다. 자신의 데이터베이스. 대기 머신은 호스트에 연결하기 위해 사용자 계정이 필요하므로 다음과 같이 호스트에 계정을 생성하고 FILE 권한만 부여하십시오.
GRANT FILE ON *.* TO 복제@10.1.1.2 IDENTIFIED BY 비밀번호 ;
대기 머신이 메인 머신에 연결될 수 있으려면 FLUSH PRIVILEGES가 메인 머신에서 실행되어야 하지만 걱정하지 마세요. 다음에서 서버를 중지할 것이기 때문입니다. 단계.
이제 호스트 데이터베이스의 스냅샷이 필요하고 바이너리 업데이트 로그가 생성될 수 있도록 호스트를 구성해야 합니다. 먼저 바이너리 업데이트 로깅을 허용하도록 my.cnf 파일을 편집하여 [mysqld] 섹션 아래 어딘가에 log-bin 줄을 추가합니다. 다음에 서버가 시작되면 호스트는 바이너리 업데이트 로그(이름:
모든 데이터베이스를 확보했는지 확인하세요. 그렇지 않으면 복사할 때 기본 머신에는 테이블이 있지만 대기 머신에는 테이블이 없으면 오류로 인해 종료됩니다. 이제 데이터의 스냅샷과 스냅샷이 생성된 이후 데이터베이스에 대한 모든 변경 사항에 대한 바이너리 로그가 생겼습니다. MySQL 데이터 파일(*.MYD, *.MYI 및 *.frm)은 파일 시스템에 따라 다르므로 Solaris에서 Linux로의 파일 전송만 수행할 수는 없습니다. 이기종 서버 환경에 있는 경우 mysqldump 유틸리티 또는 기타 사용자 정의 스크립트를 사용하여 데이터의 스냅샷을 가져와야 합니다.
2단계: 백업 머신 구성
계속하겠습니다. 대기 머신에서 MySQL 서비스 프로그램을 중지하고 호스트 머신에서 복사한 데이터베이스 디렉터리를 대기 머신의 데이터 디렉터리로 이동합니다. 반드시 디렉터리의 소유자와 그룹을 MySQL 사용자의 해당 값으로 변경하고, 파일 모드를 660(소유자와 그룹만 읽기 및 쓰기 가능)으로, 디렉터리 자체는 770으로 수정하시기 바랍니다. (소유자 및 그룹에만 해당) 읽기, 쓰기 및 실행 가능)
계속하세요. 백업 머신에서 MySQL 서비스 프로그램을 시작하고 MySQL이 제대로 작동하는지 확인합니다. 몇 가지 선택 쿼리(쿼리를 업데이트하거나 삽입하지 않음)를 실행하여 첫 번째 단계에서 얻은 데이터 스냅샷이 성공적인지 확인합니다. 그런 다음 테스트가 성공한 후 MySQL 서비스 프로그램을 종료합니다.
호스트의 변경 사항을 수신하기 위해 대기 머신에서 액세스해야 하는 호스트를 구성합니다. 따라서 서버에서 my.cnf 파일을 편집하고 [mysqld] 섹션에 다음 줄을 추가해야 합니다:
master-host=10.1.1.1
master-user=replicate
master-password=password
대기 서비스 프로그램이 시작된 후 대기 서비스 프로그램은 my.cnf 파일에 지정된 호스트를 확인하여 변경 사항이 있는지 확인하고 이러한 변경 사항을 자체 데이터베이스에 병합합니다. 대기 시스템은 호스트의 master.info 파일에서 수신된 호스트의 업데이트 기록을 유지 관리합니다. 대기 스레드의 상태는 sql 명령어 SHOW SLAVE-STATUS를 통해 확인할 수 있다. 대기 머신에서 바이너리 로그를 처리할 때
오류가 발생하면 대기 머신 스레드가 종료되고 *.err 로그 파일에 메시지가 생성됩니다. 그런 다음 오류를 수정하고 SQL 문 SLAVE START를 사용하여 대기 스레드를 다시 시작할 수 있습니다. 스레드는 호스트 바이너리 로그 처리가 중단된 지점부터 처리를 계속합니다.
이때 메인 머신에서 발생한 데이터 변경 사항이 대기 머신에 복사되어야 합니다. 이를 테스트하려면 메인 머신에 레코드를 삽입하거나 업데이트하고 대기 머신에서 이 레코드를 선택하면 됩니다. 기계.
이제 머신 A에서 머신 B로 마스터-슬레이브 관계가 생겼습니다. 이를 통해 머신 A가 충돌할 때 모든 쿼리를 머신 B로 리디렉션할 수 있지만, 머신 A가 복원되면 더 이상 쿼리를 보낼 수 없습니다. 머신 A의 변경 사항을 복원하는 방법 이 문제를 해결하기 위해 머신 B에서 머신 A로 마스터-슬레이브 관계를 만듭니다.
3단계: 상호주종관계 형성
먼저, 머신 B의 my.cnf 파일에서 [mysqld] 섹션에 log-bin을 추가하고 mysqld를 다시 시작한 다음 복제 기능을 수행할 수 있는 사용자 계정을 생성합니다.
GRANT FILE ON *.* TO 복제@10.1.1.1 IDENTIFIED BY 비밀번호;
복제 사용자를 추가한 후 머신 B에서 FLUSH PRIVILEGES 명령을 실행하여 복제 사용자를 추가한 후 머신 A로 돌아갑니다. 추가 my.cnf에 다음 줄을 추가합니다.
master-host=10.1.1.2
master-user=replicate
master-password=password
서비스 후 머신 A를 다시 시작합니다. 이제 우리는 기계 A와 기계 B 사이에 상호 마스터-슬레이브 관계를 갖게 되었습니다. 어떤 서버에서 레코드가 업데이트되거나 레코드가 삽입되더라도 해당 레코드는 다른 서버로 복사됩니다. 참고: 대기 시스템이 바이너리 로그 변경 사항을 얼마나 빨리 병합할 수 있는지 잘 모르겠습니다. 따라서 이 방법을 사용하여 삽입 또는 업데이트 문 로드 밸런싱을 수행하는 것은 좋은 생각이 아닐 수 있습니다.
4단계: 데이터베이스 연결 프로그램 수정
이제 A 머신과 B 머신 간의 상호 관계를 설정했으므로 이 방법의 이점을 얻을 수 있도록 데이터베이스 연결 프로그램을 수정해야 합니다. 다음 함수는 먼저 A 머신에 연결을 시도하고, 연결이 설정되지 않으면 B 머신에 연결합니다.
/**************************************************** ****
함수 db_connect()
성공 시 링크 식별자를 반환하고 오류 시 false를 반환합니다
******************** *************************************/
function db_connect(){
$username = "replUser";
$password = "password";
$primary = "10.1.1.1";
$backup = "10.1.1.2";
# 기본 연결 시도
if(!$link_id = @mysql_connect($primary, $username, $password ))
# 보조 연결 시도
$link_id = @mysql_connect($secondary, $username, $password)
return $link_id;
}
?>
위의 기술을 이용하여 데이터베이스 연결 설정 과정을 두 가지 상황에서 테스트해보았는데, 하나는 메인 MySQL 서비스 프로그램이 종료되었으나 서버는 계속 실행중인 경우이고, 다른 하나는 메인 서버가 종료되는 경우입니다. mysqld만 종료되면 연결은 즉시 백업 시스템으로 전송되지만, 전체 서버가 종료되면 무한 대기가 발생합니다(2분 후에 추적을 포기했습니다. 이는 매우 짧은 주의 시간입니다). 존재하지 않는 서버를 찾고 있습니다. 불행하게도 fsockopen 함수와 달리 mysql_connect 함수에는 시간 초과 매개변수가 없지만 fsockopen을 사용하여 시간 초과를 시뮬레이션할 수 있습니다.
5단계: 향상된 데이터베이스 연결 프로그램
/**************************************************** ****
함수 db_connect_plus()
성공 시 링크 식별자를 반환하고 오류 시 false를 반환합니다
******************** *************************************/
function db_connect_plus(){
$username = "username";
$ 비밀번호 = "password";
$primary = "10.1.1.1";
$backup = "10.1.1.2";
$timeout = 15; // 시간 초과(초)
if ($fp = fsockopen($primary, 3306, &$errno, &$errstr, $timeout)){
fclose($fp);
return $link = mysql_connect($primary, $username, $password );
}
if($fp = fsockopen($secondary, 3306, &$errno, &$errstr, $timeout)){
fclose($fp);
return $ link = mysql_connect($secondary, $username, $password);
}
return 0;
}
?>
이 새롭게 개선된 기능은 다음을 제공합니다. mysql_connect 함수에는 없는 조정 가능한 시간 초과 기능이 있습니다. 연결이 즉시 실패하면(예: 머신이 "활성"이지만 mysqld가 "다운"된 경우) 함수는 즉시 두 번째 서버로 이동됩니다. 위의 기능은 매우 강력합니다. 서비스 프로그램이 지정된 포트에서 수신 대기하는지 확인하기 위해 연결을 시도하기 전에 테스트하십시오. 허용되는 시간이 지나면 스크립트가 시간 초과되도록 하여 오류 조건을 적절하게 처리할 수 있습니다. 기본 포트인 3306을 수정하는 경우 반드시 포트 번호를 수정하시기 바랍니다.
결론 및 설명
우선 전체 데이터 스냅샷을 확보해야 합니다. 테이블이나 데이터베이스 복사를 잊어버리면 대기 라인 프로그램이 중지됩니다. 스냅샷이 생성되는 시간이 중요합니다. 데이터 파일을 복사하기 전에 바이너리 로깅 기능이 비활성화되어 있는지 확인해야 합니다. 스냅샷을 찍기 전에 바이너리 로그 기능을 활성화하면 스레드가 중요한 레코드를 가져오려고 할 때 기본 키가 중복되어 중지될 수 있으므로 대기 머신의 스레드가 중지될 수 있습니다. 가장 좋은 방법은 2부에서 설명한 솔루션을 따르는 것입니다. 닫기-복사-바이너리 로그 기능을 다시 시작하도록 허용합니다.
복제 프로세스를 원래 방식으로 구성하고, 대기 머신이 마스터 머신과 동기화되도록 적절한 시점에 대기 머신에 주의를 기울이는 것이 좋습니다.
복제 기능을 사용하는 시스템의 로드 밸런싱 성능을 테스트하지는 않았지만 삽입과 업데이트의 밸런싱을 위해 이러한 시스템을 유연하게 사용할 수 있을 것입니다. 예를 들어, 두 서버의 두 레코드가 동일한 auto_increment 값을 제공하는 경우 대기 스레드는 어느 레코드에서 중지됩니까? 이와 같은 문제가 발생하면 로드 밸런싱이 읽기 전용으로 처리되어 하나의 서버가 모든 삽입 및 업데이트를 처리하는 반면 대기 세트(예, 마스터와 별도로 여러 대기를 가질 수 있음)가 모든 선택을 처리하게 됩니다.
MySQL에 이미 복제 시스템의 일부 기능이 있고 구성이 매우 간단하다는 점이 매우 기쁩니다. 이를 사용하면 제어할 수 없는 이벤트에 대해 추가 보안을 제공할 수 있습니다. 나는 테스트하고 사용한 복제 기능에 대해서만 다루었지만 MySQL 온라인 설명서의 Part 11에 더 자세히 설명되어 있습니다. .
위 내용은 MySQL에 내장된 복제 기능을 활용하여 가용성을 최적화한 내용입니다. 더 많은 내용을 얻고 싶으시다면 PHP 중국어 홈페이지(www.php.cn)를 주목해주세요!