MySQL 서버를 자동 확장하는 방법은 무엇입니까?

8

트래픽이 급증하는 사이트를 운영하고 있으며 이로 인해 자동 확장 솔루션으로 인해이 경우 매우 수익성이 높습니다. 현재 웹 서버는 수평 적으로 자동 확장 할 수 있지만 병목 현상은 MySQL 서버에 있습니다.

Amazon RDS Multi-AZ를 사용해 보았지만 12GB 데이터베이스를 몇 분의 다운 타임으로 업그레이드하는 데 15 분 정도 걸립니다. 특정 순간에 트래픽 급증이 발생한다는 것을 이미 알고 있었을 때 많은 도움이되었습니다.
나는 또한 Xeround를 고려했습니다. 이 크기의 데이터베이스에는 비용이 많이 들지만 이것이 가장 좋은 솔루션 일 것입니다. 어쨌든 그것은 합법적으로 데이터베이스가 유럽 연합에 있어야하기 때문에 옵션이 아닙니다.
나는 Scalr에 대해 읽었지만 그것이 도움이 될 수 있는지 확실하지 않습니다.
많은 클라우드 호스팅 제공 업체가 수직 확장 솔루션을 제공한다는 것을 알았습니다. 그것은 해결책 일 수는 있지만 다운 타임이 없는지 여부와 MySQL 구성 (및 OS의 다른 많은 것들)이 다운 타임없이 어떻게 업그레이드 할 수 있는지 궁금합니다.
MySQL 슬레이브 서버로 시도했지만 전혀 도움이되지 않았습니다.
많은 도움이되는 memcache를 사용하고 있지만 충분하지 않습니다. 읽기 때문이 아니라 쓰기 때문에 업그레이드해야합니다.

어떤 제안? 미리 감사합니다

— 질로
소스

당신은 나와 같은 문제에 갇혀있는 것처럼 보입니다. mysql을의.

— 니코 SP

"MySQL 슬레이브 서버로 시도했지만 전혀 도움이되지 않았습니다"에 대한 자세한 내용을 추가 할 수 있습니까? 아키텍처를 어떤 방식으로 변경 했습니까?

— nickgrim

1

우리가 사용하는 소프트웨어는 원한다면 MySQL 슬레이브 서버를 사용하도록 이미 설계되었지만 그럼에도 불구하고 전혀 도움이되지 않았습니다. memcache는 거의 모든 MySQL 슬레이브 작업 (대부분의 읽기)을 수행한다고 생각합니다. 나는 MySQL 슬레이브가 긍정적 인 것보다 더 큰 문제라고 생각하지만 어쨌든 각 경우에 달려 있습니다. 어쩌면 어떤 경우에는 유용하지만 다른 경우에는 그렇지 않습니다.

— Zillo

4

실제로 더 간단한 솔루션은 Memcached를 스택에 추가하여 DB로드를 절약하는 것입니다. 이렇게하면로드를 크게 절약 할 수 있으며 서버를 빠르게 세우고 (낮은 난이도) 문제를 해결 한 다음 빠른 MySQL 동기화 (훨씬 높은 난이도)를 해결하는 것보다 훨씬 간단합니다.

~~http://toblender.com/?s=memcached~~

너무 많은 쓰기 문제를 해결하기 위해 가장 일반적인 수정은 서버에 메모리를 추가하고 (더 큰 작업 세트는 RAM에 보관할 수 있음) DB를 더 빠른 디스크 (SSD는 좋은 솔루션이지만 비싸다) 또는 샤딩에 배치하는 것입니다 (추가 서버와 복잡성이 비싸다).

DB 쓰기로드를 줄이는 또 다른 방법은 메모리 내 데이터 저장소 (예 : Redis)를 통합하여 자주 변경되는 데이터를 처리하고 필요한 경우 주기적으로 변경 사항을 주 DB에 다시 쓰는 것입니다.

— 왈도
소스

memcached가 mysql 서버의 쓰기로드를 줄이는 데 어떻게 도움이되는지에 대한 예를 들어 줄 수 있습니까?

— Niko SP

1

사과; 나는 그 부분을 보지 못했다.

— gWaldo

쓰기 지연 문제를 해결하기 위해 답변이 업데이트되었습니다.

— gWaldo

SSD 제안은 비용이 많이 들고, 그러한 작은 데이터베이스에 SSD가 반드시 비싼 것은 아닙니다. 더 큰 데이터베이스에서도 ZFS를 사용하면 모든 쓰기를 SLC 플래시에 직접 캐시 할 수 있습니다.

— Skyhawk

네가 옳아; 12GB DB 용 SSD는 전혀 비싸지 않습니다. OP의 특정 매개 변수보다 더 일반적인 경우를 생각하고있었습니다.

— gWaldo

3

스타 토폴로지 사용을 고려해야합니다

여기 내가 제안하는 것이 있습니다

원 쓰기 마스터 (일명 WM)
하나의 배포 마스터 (일명 DM)
5 개의 읽기 슬레이브 서버 (일명 RSS)

이와 같은 토폴로지 준비

01 단계 : 이러한 공통 옵션으로 5 RSS 설정

[mysqld]
skip-innodb
key_buffer_size=1G

이렇게하면 MyISAM Storage Engine으로로드 된 모든 테이블이 생성됩니다.

02 단계 : DM 및 모든 RS 서버 설정

mysqldump WM에서 schemadump 파일로 모든 테이블의 스키마
schemadump 파일을 DM 및 모든 5 RSS에로드
tblname ROW_FORMAT=Fixed;RSS의 모든 테이블에서 ALTER TABLE 실행
tblname ENGINE=BLACKHOLE;DM의 모든 테이블에서 ALTER TABLE 을 실행하십시오.
데이터 덤프에 대한 mysqldump 데이터 만 (--no-create-info 사용)
모든 5 RSS에 데이터 덤프로드

03 단계 : DM에서 모든 5 RSS로 복제 설정

04 단계 : WM에서 DM으로 복제 설정

설치 종료

다음은 읽기 / 쓰기 메커니즘의 작동 방식입니다

모든 쓰기 (INSERT, UPDATE, DELETE)는 WM에서 발생합니다.
SQL은 DM의 이진 로그에 기록됩니다 (DM에 실제 데이터가 없음)
각 RSS는 DM에 대한 읽기 슬레이브입니다
모든 읽기는 RSS에서 발생합니다

이제 캐치가 있습니다 ...

처음 읽을 때 RSS 1-4를 사용합니다.
5 번째 RSS를 사용하여 다른 RSS를 가동 시키십시오
- 당신 service mysql stop은 다섯 번째 RSS에서 실행
- 다른 RSS를 올리십시오
- 5 번째 RSS의 / var / lib / mysql 및 /etc/my.cnf를 새로 분리 된 RSS에 복사
- 당신 service mysql stop은 다섯 번째 RSS에서 실행
- 당신 service mysql stop은 새로운 RSS에서 실행

RSS # 5를 사용하여 새 서버를 계속해서 반복 사용할 수 있습니다

참고로, InnoDB 또는 BLACKHOLE 스토리지 엔진을 지원하지 않으므로 WM 또는 DM에는 XEROUND를 사용하지 마십시오.

이 아이디어가 도움이되기를 바랍니다.

— RolandoMySQLDBA
소스

1

Innodb를 사용하는 경우 Galera가 관리하는 Mysql 다중 마스터를 고려해야 합니다. mysql 멀티 마스터 설정이 쉬워지고 자동 스케일을 "세미"하는 것이 더 쉬워집니다.

이것이 귀하 또는 귀하의 회사에서 작성하는 응용 프로그램 인 경우 응용 프로그램의 샤드 (파티션) 설계로 이동하는 것을 고려할 수 있습니다. 그러나 샤딩은 복잡해질 수 있습니다. 다음은 시작할 수 있는 링크 입니다.

할당 된 적절한 메모리 등에서와 같이 mysql 설정 파일을 "조정"했다고 가정합니다.

— 지금은 아님
소스

1

이것이 당신이 통제하는 랙에 있습니까, 아니면 클라우드에 있습니까? 12GB는 사용 가능한 디스크 크기에 비해 매우 작은 데이터베이스입니다. 소형 SLC SSD의 RAID1 또는 RAID10 어레이에 배치하면 쓰기 대기 시간이 사라집니다.

인텔 311 시리즈 20기가바이트 SLC SSD ($ (120) 각각은) 훌륭하게 일을 할 것입니다.

데이터베이스가 더 큰 경우 데이터베이스를 ZFS SAN 서버 (Nexenta, OpenIndiana, FreeNAS 등을 사용하여 상용 서버 하드웨어에 구축)의 iSCSI 대상으로 이동하고 비슷한 SSD 미러를 설정하여 비슷한 결과를 얻을 수 있습니다. ZIL 쓰기 캐시 가장 특별한 상황을 제외하고 기가비트 이더넷은 데이터베이스 iSCSI 트래픽을 이동시키기에 충분합니다.

— 스카이 호크
소스