성능을 위해 MySQL의 내구성을 줄입니다.

Question

내 사이트는 때때로 정상적인 처리량보다 100 배 이상 처리량을 늘릴 수있는 예측 가능한 트래픽 폭발이 있습니다. 예를 들어, 우리는 TV 쇼에 출연 할 예정이며, 쇼가 끝난 후 한시간 내에 정상보다 100 배 이상의 트래픽을 얻을 것으로 기대합니다.

나의 이해는 MySQL을 (이노)는 일반적으로 다른 장소의 무리에서 내 데이터를 유지한다는 것입니다 :

• RAM 버퍼
• commitlog
• 바이너리 로그
• 실제 테이블
• 의 모든 내 DB에 위의 장소에 슬레이브

이것은 EC2 노드에 있고 대부분의 것들이 동일한 네트워크 파이프 (파일 시스템은 네트워크에 연결되어 있음)를 통과하기 때문에 너무 많은 "내구성"입니다. 게다가 드라이브가 느립니다. 데이터는 가치가 높지 않으며 군중이 도착했을 때 정전의 가능성이 높지 않고 데이터 손실이 발생할 수있는 기회가 적습니다.

이러한 트래픽이 발생하는 동안 나는 그 모든 I/O 에만을주고 싶습니다. 가능한 한 많은 RAM을 유지하고 싶습니다 (한 시간 동안 만져야하는 데이터 크기에 비해 상당히 많은 양의 RAM이 있습니다). 버퍼가 부족하거나 I/O 채널에 과부하가 걸리지 않는다면 커밋 로그 또는 바이너리 로그로 이동하여 슬레이브로 보내주기 바란다. I/O 채널이 오버로드되지 않은 경우에만 실제 테이블에 다시 쓰고 싶습니다.

즉, MySQL/InnoDB가 "write through"캐시 알고리즘보다는 "write back"캐시 알고리즘을 사용하기를 바랍니다. 그렇게하도록 설득 할 수 있습니까?

이것이 가능하지 않다면 일반적인 MySQL 쓰기 성능 최적화 팁에 관심이 있습니다. 대부분의 문서는 읽기 성능을 최적화하는 데 대한 것이지만 사용자가 많아지면 모든 계정을 만들므로 글쓰기가 많은 작업량입니다.

Answer 1

상당 부분 InnoDB가 이미 이것을 수행합니다.

데이터를 커밋 할 때 복구를 위해 로그 파일에 기록되지만 테이블 공간 (데이터)에 대한 수정은 나중에 백그라운드 프로세스 ('checkpoint')로만 수행됩니다.

당신은 새로운 이노 릴리스 (innodb_io_capacity)에서 그 백그라운드 프로세스에 바치고 싶은 얼마나 많은 IOPS (http://en.wikipedia.org/wiki/IOPS)를 지정하고 충분한 이노 그냥 잠시 동안 뒤쳐 및 백업 잡을 것이다 innodb_log_file_size를 설정하는 것이 제공 할 수 있습니다 후에.

InnoDB가 백그라운드 작업에서 너무 늦게 떨어지면 로그 파일의 끝에 도달했을 때 성능이 크게 저하 될 수 있으며 다시 돌아와야합니다.다음 벤치 마크에서 'none'행을 참조하십시오. http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/

Answer 2

추가 위험에 노출 될 수있는 경우이 두 가지 변경 사항은 쓰기 성능을 크게 향상시킵니다.

설정에서 innodb_flush_log_at_trx_commit = 0
설정 sync_binlog을은 = 0

또한, 당신의 버퍼 풀 크기는 서버 메모리의 약 70-80%해야한다. 로그 파일 크기와 로그 버퍼 크기를 늘리면 어느 정도 도움이 될 수 있습니다.