Dmitri Joukovski와 Pavel Pragin

MySQL 데이터베이스는 일관된 빠른 성능, 높은 안정성 및 사용 용이성으로 인해 세계에서 가장 인기있는 오픈 소스 데이터베이스가되었습니다. 온라인 포럼 및 관리 호스팅 제공 업체에있는 위키에 MySQL 데이터베이스를 사용하거나, Bugzilla로 버그를 추적하기 위해 원격 사무실에서 사용하거나, MySQL을 사용하는 새로운 웹 2.0 애플리케이션 개발에 대해 생각하고있을 수 있습니다. . 어느 쪽이든 MySQL 데이터베이스에 저장된 정보를 중요하게 생각한다면 데이터베이스 애플리케이션에 미치는 영향을 최소화하면서 성공적이고 안전하며 일관된 MySQL 백업을 보장해야합니다. 백업 솔루션이 네트워크, 서버 및 스토리지 리소스를 가장 효율적으로 사용하는지 확인하십시오.

사용하기 쉬우면서도 유연하고 강력한 MySQL 백업 및 복구를 제공하여 생활을 단순화하는 솔루션을 찾고 있다면 Zmanda Recovery Manager (ZRM)가 적합한 선택 일 수 있습니다. 에 대한 세부 정보 ZRM 기능은 여기에서 사용할 수 있습니다.

데이터베이스 백업의 경우 기본 고려 사항은 백업의 일관성과 사용자 및 애플리케이션에 대한 영향입니다. 그러나 원격 MySQL의 백업에는 다음과 관련된 추가 문제가 있습니다.

  • 네트워크 사용량
  • 보안 및
  • MySQL 데이터를 다른 호스트로 복구 할 수있는 유연성.

MySQL 환경을 완전히 제어 할 수없고 다른 버전의 MySQL 서버 또는 다른 운영 체제를 사용하는 다른 관리 호스팅 제공 업체로 데이터를 복구 할 수있는 옵션을 원할 때 마지막 지점이 중요 할 수 있습니다.

증분 백업은 마지막 전체 또는 마지막 증분 백업 이후의 변경 사항 만 유선으로 이동되기 때문에 백업 창과 네트워크 사용량을 크게 줄입니다. ZRM을 사용하면 여러 증분 백업 이미지를 사용하여 데이터를 특정 시점으로 되돌려 야하는 경우에도 증분 백업에서 데이터를 쉽게 복구 할 수 있습니다. 증분 백업을하려면 MySQL 바이너리 로그를 활성화해야하지만 MySQL 설명서에 따르면 바이너리 로그를 활성화하면 1% 미만의 성능 저하.

논리 백업은 백업 파일이 데이터베이스 스키마와 내용을 모두 다시 생성하는 모든 MySQL 문을 포함하는 텍스트 파일이기 때문에 복구에 더 많은 유연성을 제공합니다. 논리적 백업은 MySQL 클러스터링에 사용되는 NDB 엔진을 제외한 모든 스토리지 엔진에서 작동합니다. 논리적 백업의 가장 큰 장점은 데이터베이스 복구의 유연성입니다. MySQL의 논리적 백업을 다른 아키텍처 및 다른 데이터베이스로 복원 할 수 있습니다. 논리적 ZRM 백업 이미지의 이동성 덕분에 ZRM은 마이그레이션을위한 편리한 도구가됩니다. 예를 들어 MySQL 데이터를 이동할 수 있습니다.

  • Solaris의 MySQL에서 Linux의 MySQL로
  • 한 스토리지 엔진에서 다른 스토리지 엔진으로
  • 32 비트 서버에서 64 비트 서버로
  • 하나의 관리 호스팅 공급자에서 데이터 센터 또는 MySQL 구성이 다른 다른 공급자로

물론 이러한 유연한 복구 비용은 지불해야합니다. 모든 MySQL 문을 읽고 재생해야하므로 논리적 백업에서 데이터를 복원하는 데 시간이 오래 걸릴 수 있습니다. 또 다른 단점은 논리적 백업의 크기를 예측하기 어려울 수 있다는 것입니다. 데이터 유형 및 데이터베이스 스키마에 따라 논리적 백업의 크기가 데이터베이스 자체보다 클 수 있습니다. 한 가지 해결책은 논리 백업이 기본적으로 텍스트 파일이기 때문에 일반적으로 적절한 압축을 얻을 수 있다는 것입니다.

원시 백업은 백업이 바이너리 파일 인 데이터베이스의 일관된 복사본을 제공합니다. 논리 백업에 비해 원시 백업의 장점은 다음과 같습니다.

  • 백업 및 특히 복구가 훨씬 빠릅니다. 예를 들어, 크기가 4 ~ 5GB 인 동일한 데이터베이스의 경우 원시 백업이 논리적 백업보다 5 배 빠르며 원시 백업 이미지의 복구가 논리적 백업 이미지의 복구보다 20 배 빠릅니다. 영상.
  • 백업은 데이터베이스의 복사본 일 뿐이므로 항상 정확한 백업 크기를 알 수 있습니다.
  • MySQL 데이터베이스가 10-20GB 이상과 같이 다소 큰 경우 중요 할 수있는 더 나은 확장 성을 제공합니다.

원시 백업은 원본 데이터와 동일한 운영 체제에서 동일한 버전의 MySQL 서버로만 복구 할 수 있습니다. 즉, MySQL의 원시 백업 이미지를 다른 관리 호스팅 제공 업체로 복구 할 가능성이 그리 높지 않으므로 원시 백업과 논리적 백업을 선택할 때이를 고려해야합니다.

원시 및 논리적 백업 모두 웜 백업을 제공하므로 백업을 위해 MySQL 서버를 종료 할 필요가 없지만 백업 중에 모든 테이블이 잠기고 사용자가 데이터를 입력 할 수 없습니다. 그렇기 때문에 정의한 임계 값에 따라 백업을 지연시킬 수있는 ZRM 스케줄링 플러그인 사용을 고려해야합니다. 예를 들어 50 명 이상의 사용자가 데이터베이스에 액세스하는 경우 한 시간 동안 백업을 연기 할 수 있습니다.

MySQL의 원격 백업에 대한 중요한 고려 사항 중 하나는 ZRM과 원격 MySQL 서버간에 설정할 연결 유형을 결정하는 것입니다. ZRM은 소켓 기반 연결을위한 플러그인과 SSH 기반 연결을위한 또 다른 플러그인을 제공합니다. ZRM의 유연한 아키텍처를 통해 사용자는 자신의 플러그인을 작성할 수 있습니다.

이름에서 알 수 있듯이 소켓 복사 플러그인은 IP 기반 네트워크를 통해 ZRM과 MySQL 간의 통신을 제공하는 소켓을 설정합니다. 소켓 복사 플러그인을 사용하려면 MySQL 서버에서 xinetd 서비스를 실행하고 기본 포트 25300을 열어야합니다. 필요한 경우 백업 관리자가 포트를 변경할 수 있습니다. 소켓 복사 플러그인은 안전하지 않으며 보안이 중요하지 않거나 다른 수단으로 보안이 설정된 경우 (예 : ZRM과 원격 MySQL 서버간에 VPN 연결이있는 경우)에만 사용해야합니다.

SSH 복사 플러그인은 ZRM과 원격 MySQL 서버간에 보안 채널을 제공합니다. 공개 키 암호화를 사용하여 원격 MySQL 서버와 ZRM을 실행하는 백업 사용자를 인증합니다. SSH 플러그인을 사용하려면 표준 TCP 포트 22가 열려 있고 SSH 데몬이 실행 중이어야합니다. SSH 복사 플러그인은 백업 데이터의 보안이 중요한 경우에 가장 적합합니다. SSH 연결은 암호화를 위해 추가 CPU주기를 필요로하기 때문에 소켓 연결을 사용한 백업에 비해 백업 성능이 저하 될 수 있습니다.

다음 표에는 MySQL의 원격 백업을 위해 소켓 대 SSH 복사 플러그인을 선택할 때 고려할 사항이 요약되어 있습니다.

원격 연결
플러그인
사용 된 포트 보안 상대 성능 설치 설명
SSH 복사 22 (고정) 유선을 통해 백업 데이터를 이동하기위한 강력한 인증 및 암호화를 제공합니다. 성능이 낮으며 MySQL 서버 메모리, CPU 리소스 및 사용 가능한 대역폭에 따라 다릅니다. 종종 백업 및 복구 이외의 이유로 이미 설정된 원격 MySQL 서버에 대한 SSH 연결이있을 수 있습니다. 그렇지 않으면 ZRM과 MySQL 서버간에 SSH 연결을 설정해야합니다.
소켓 복사 25300 (변경 가능) 유선을 통한 백업 데이터는 안전하지 않습니다. 더 높은 성능 MySQL 서버에 추가 소프트웨어를 설치해야합니다. 예를 들어, ZRM 1.1의 Enterprise 버전의 경우 MySQL-zrm-enterprise-socket-server-1.1-1.noarch.rpm을 사용합니다. 커뮤니티 버전의 경우 정확한 패키지는 다운로드 페이지를 참조하십시오.

더 자세한 기술 정보는 Zmanda 네트워크에 무료로 등록하고이 백서의 전체 버전을 다운로드하십시오. 몇 가지 일반적인 시나리오에 ZRM을 사용하는 방법을 배웁니다. 예를 들어,이 사용 사례를 위해 SSH 복사 플러그인을 사용하여 유선 및 미사용 데이터로 백업을 수행하는 방법에 대한 기술적 세부 정보를 제공합니다.

인터넷을 통한 ZRM

또한 소켓 복사 플러그인을 사용하여보다 효율적인 논리 및 원시 백업에 대한 기술 세부 정보를 제공합니다.

모든 풍부한 기능을 갖춘 ZRM for MySQL은 특정 데이터 보호 요구에 최적 인 백업 및 복구 전략을 구현하기위한 도구 일뿐입니다. ZRM은 강력하고 사용하기 쉽지만 원격 MySQL 서버의 자체 구현과 백업 및 복구에 대한 특정 요구 사항에 따라 ZRM for MySQL에서 제공하는 각 운영 옵션과 관련된 모든 장단점을 고려해야합니다.

참조 :
MySQL 용 ZRM
MySQL Wiki 용 ZRM
Zmanda 포럼