예산에 따른 다운 타임없는 MySQL 백업

현재 MySQL 백업 시나리오는 DB를 두 번째 서버에 복제하고 해당 서버에서 mysqldump를 실행하여 테이블 또는 행 잠금에서 중단 시간을 제거하는 것입니다. 이것은 잘 작동하지만 두 번째 서버의 경우 월 $ 150입니다 (호주 호스팅은 미국보다 훨씬 비쌉니다).

나는 이것에 대해 많은 질문을 읽었습니다. 대부분의 사람들은 예약 된 백업에 대한 도움이 필요하며 필요한 것은 아닙니다. 다운 타임없이 mysqldump (바람직하게는 4 시간마다)가 필요합니다. db는 ~ 7GB 압축되지 않으므로 mysqldump는 서버에 따라 시간이 걸릴 수 있습니다.

나는 같은 머신으로 복제하는 것을 고려했지만, 슬레이브가 필요한 메모리에 많이 들어가기를 원하지 않았습니다. DB별로 메모리 사용량을 제한 할 수 있는지 잘 모르겠습니다. 어느 쪽이든, 이것은 db를 덤프하는 동안 서버에 부하를 줄 것입니다.

방금이 http://www.zmanda.com/quick-mysql-backup.html을 읽었 으며 좋아 보입니다. 연간 300 달러가 괜찮아서 많은 시간을 절약 할 수 있습니다.

불행히도 Amazon의 RDS에는 복제 할 수 없지만 마이크로 RC2 인스턴스에는 복제 할 수 있지만 복제는 인터넷을 통해 이루어지며 핑은 ~ 220ms입니다.

LVM 스냅 샷에 대해 이야기하는 몇몇 사람들이 좋은 옵션이라고 생각했습니다. 나는이 옵션에 대해 많은 것을 모른다.

의견은 크게 감사하겠습니다.

innodb 테이블을 사용하면

http://www.percona.com/docs/wiki/percona-xtrabackup:start

잠금없이 도구로 가져올 수있는 데이터베이스 덤프가 필요합니다. 나는 당신이 myisam 테이블을 가지고 있다면 그것들을 잠급니다.

innodb 또는 완전히 거래되는 다른 백엔드를 사용하는 경우을 사용할 수 있습니다 mysqldump --single-transaction .... 나는 이것을 아주 큰 (~ 100GB) 데이터베이스에서 좋은 결과로 사용했습니다. 데이터베이스에로드가 많은 경우 몇 시간 이 걸릴 수 있지만 테이블을 잠그지 않고 작동합니다. 복제가 일반적으로 더 좋지만 때로는 멋진 솔리드 덤프 파일이 필요합니다. mysql 복제 슬레이브도 덤프 할 수 있습니다.

mysqldump 페이지에서 (트랜잭션으로 유출되는 작업에 대한주의 사항을 참고하십시오) :

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

대기 시간이 긴 연결을 통해 미국의 저렴한 VPS로 복제하는 데 많은 문제가 발생하지 않습니다. 대기 시간이 길다는 것은 실제로 그렇게 큰 문제가되지 않아야합니다. 복제는 슬레이브가 몇 시간 뒤 떨어질 때에도 빠르게 따라 잡을 수 있도록 설계되었습니다 . 즉, 비동기 적으로 작동 할 수 있습니다.

호주의 호스팅 계획에서 많은 발신 대역폭을 견딜 수있는 한.

대기 시간이 긴지 여부에 대한 훨씬 자세한 응답은 다음과 같습니다.

실제로 데이터베이스를 실제로 내보내는 데 걸리는 시간 만 가동 중지 시간입니다. 느리게 충분한 시간 동안 수행하면 아무런 문제가 없습니다. 해당 예산에서 실제로 기대하는 IT 부서는 무엇입니까?

최대 5-10 분 내에 7GB 데이터베이스를 mysqldump 할 수 있고 읽기 / 쓰기 잠금을 해제하면 가동 중지 시간이 종료됩니다. 그런 다음 새 서버로 7GB 파일을 전송하는 가장 효과적인 방법을 찾을 수 있습니다 (읽기 : 고압축). 새 서버에서 파일을 전송하고 MySQL로 가져올 시간이 충분합니다. 그런 다음, 마스터 로그 정보를 입력하고 복제를 시작하십시오. 케이크 조각이어야합니다!

MySQL 문서는 환상적입니다 : http://dev.mysql.com/doc/refman/5.0/en/replication.html

DB별로 메모리 사용량을 제한 할 수 있는지 잘 모르겠습니다.

물론 가능합니다-다른 /etc/my.cnf로 슬레이브를 실행하면됩니다.

nice / renice 및 taskset을 사용하여 마스터 및 슬레이브에서 스케줄링 우선 순위 / CPU 선호도를 조작하는 작업을 수행 할 수도 있습니다 (Linux 서버라고 가정).

그러나 복제는 인터넷을 통해 이루어지며 핑은 ~ 220ms입니다.

지연 시간은 관련성이 거의 없습니다. 중요한 것은 대역폭입니다. 세션 데이터를 복제하지 않는다고 가정 할 때 데이터베이스 대역폭은 HTTP 대역폭보다 몇 배나 작습니다.

가동 중지 시간없이 [일관된 데이터베이스 백업] (바람직하게는 4 시간마다)을 작성해야합니다.

그러나 당신이 논의하는 전략은 그 당시의 어떤 것도 회복을 허용하지 않습니다.

가장 저렴한 옵션은 동일한 컴퓨터의 슬레이브가 될 것입니다. 재구성 할 수있는 것 이상의 성능에 부정적인 영향을 미치는 경우 현재 호스팅 패키지를 업그레이드하십시오.

연결이 끊긴 슬레이브 (현재 서버에서 bin 로그 활성화)를 실행할 수도 있습니다. 백업을 가져 와서 로컬 머신에서 백업을 복원 한 다음 회전 할 때 bin 로그를 복사 한 후 로컬 DBMS에서 롤 포워드하십시오 .

나의 제안:

1-두 번째 계정 / 서버를 유지하고 원래 계정 / 서버의 데이터베이스에 복제를 구현하십시오.

2-두 번째 계정 / 서버로의 복제를 중지하십시오.

3-며칠 동안 성능을 모니터링하십시오. 사용량이 가장 많은 기간을 포함 할 수있을 정도로 오래 모니터하십시오.

4-주요 성능 문제가있는 경우 이전 설정으로 전환 할 준비를하십시오. 이것이 두 번째 계정을 유지 한 이유입니다.

5-원래 계정에서 더 많은 용량 / 업그레이드 서버를 구입하십시오. 이것은 내가 믿는 두 대의 서버를 지불하는 것보다 저렴해야합니다.

6-두 번째 계정을 취소하십시오.

행운을 빕니다!