MySQL을 사용한 Amazon RDS와 EC2의 각각의 장점 / 제한은 무엇입니까? [닫은]

나는 둘 사이의 몇 가지 기본적인 차이점, 즉

1. EC2가 더 저렴해질 것입니다

2. RDS 유지 관리를하지 않아도됩니다

이 두 가지 외에는 MySQL 서버 역할을하는 별도의 EC2 서버와 달리 RDS에서 내 데이터베이스를 실행하면 이점이 있습니다. 비슷한 인스턴스 크기를 가정하면 둘 다로드를 처리 할 수 ​​있다는 측면에서 동일한 제한을 겪게됩니까?

내 사용에 대해 조금 더 많은 정보를 제공하기 위해 데이터베이스, 너무 크거나 아무것도 (가장 큰 테이블 백만 행), 높은 SELECT 볼륨을 가지고 있습니다.

이것은 매우 복잡한 답을 가진 간단한 질문입니다!

간단히 말해 : EC2는 RAID0 EBS와 함께 사용하면 최대 성능을 제공합니다. RAID0 EBS를 수행하려면 다음과 같이 상당히 많은 유지 보수 오버 헤드가 필요합니다.

http://alestic.com/2009/06/ec2-ebs-raid

http://alestic.com/2009/09/ec2-consistent-snapshot

RAID0 EBS가없는 EC2는 까다로운 I / O 성능을 제공하므로 실제로는 옵션이 아닙니다.

RDS는 기본적으로 매우 우수한 (최대는 아니지만) 성능을 제공합니다. 관리 콘솔은 환상적이며 인스턴스를 쉽게 업그레이드 할 수 있습니다. 클릭 한 번으로 고 가용성 및 읽기 전용 슬레이브를 사용할 수 있습니다. 정말 굉장합니다.

짧은 대답 : RDS와 함께하십시오. 아직도 울타리에? RDS와 함께 가십시오 !!! 최대 성능을 위해 두통을 겪고 마지막 순간을 조금씩 조정한다면 EC2 + EBS RAID 0을 고려할 수 있습니다. Vanilla EC2는 MySQL 호스팅을위한 끔찍한 옵션입니다.

에서 이 게시물 훌륭한 벤치 마크 사이가있다 :

• 소규모 EC2 + EBS에서 MySql 실행
• 소형 EC2 + EBS + 조정 된 MySql 매개 변수에서 MySql 실행
• 작은 RDS

벤치 마크는 이상적인 조건 (단 하나의 스레드)에만 집중 될뿐만 아니라 50 개의 스레드가 데이터베이스에 충돌하는보다 현실적인 시나리오에도 초점을 맞추기 때문에 매우 좋습니다.

RDS는 실제로 고 가용성 시스템이 아닙니다. RDS FAQ에서 작은 글씨를 읽으십시오. 장애 조치 이벤트 중에 장애 조치에 최대 3 분이 소요될 수 있습니다. 추가 Amazon은 rds 인스턴스를 "업그레이드"해야한다고 결정하고 그 시점에서 "최대 3 분"동안 데이터베이스를 다운시키는 장애 조치를 수행합니다 (우리의 경험은 그보다 오래 걸릴 수 있음).

RDS 고 가용성은 마스터-마스터 또는 마스터-슬레이브 복제와 매우 다르며 훨씬 느립니다. 그들은 mysql 복제를 사용하지 않지만 일종의 ebs 복제를 사용합니다. 따라서 장애 조치 상황에서 백업 머신에 ebs를 마운트하고, mysql을 시작하고, mysql이 오류 복구를 수행 할 때까지 기다립니다 (아마도 손상된 것이없는 경우). dns 스위치를 수행합니다.

이것이 평가에 도움이되기를 바랍니다.

읽기 볼륨이 높고 마스터-슬레이브 복제가 필요하기 때문에 EC2 MySQL 인스턴스를 사용하기로했습니다. 물론 여러 RDS 인스턴스를 스핀 업하고 직접 인스턴스간에 MySQL 복제를 설정할 수 있지만 EC2 인스턴스를 사용하여이를 관리하는 Scalr.net을 사용합니다.

기본적으로 Scalr에 원하는 MySQL 인스턴스 수를 유지하고 복제 설정을 자동화하며 마스터가 종료되면 마스터로 슬레이브 승격의 자동 장애 조치를 처리합니다. SQL 덤프 백업과 EBS 볼륨 스냅 샷을 모두 수행합니다. 주인. 따라서 새 슬레이브를 만들어야하는 경우 마지막 마스터 스냅 샷의 EBS 볼륨을 자동으로 임시 마운트하여 슬레이브 DB를 초기화 한 다음 적절한 지점에서 복제를 시작합니다. 포인트 앤 클릭 :)

유지 관리 기간 질문에 대해. 다중 AZ를 사용하는 경우 RDS는 다른 가용 영역에 대기 복제본을 생성하여 유지 관리를위한 중단 시간이 없으며 영역 장애로부터 사용자를 보호합니다.

이것이 다음 주 정도에 할 계획입니다. 물론 비용이 더 많이 들지만 아직 그 일을하지 않았습니다.

EC2의 MySQL 대 RDS MySQL

EC2에서 MySQL의 장점 Amazon EC2 Inter Region 복제

Amazon EC2 리전에서 스냅 샷 복사

MySQL EC2에서 EBS 스트라이핑이있는 RAID 0

EC2의 MySQL에는 3TB 이상의 디스크 공간 (크기에 따라 필요하지 않음)을 연결할 수 있습니다.

EC2에서 MySQL의 단점

RDS와 비교 한 구성, 모니터링 및 유지 관리

RDS에서 사용 가능한 특정 시점 백업

현재 RDS MySQL보다 적은 IOPS (RAID 0 이후라도)

몇 달 동안 RDS를 시험해 보았으며 여기에 몇 가지 문제가 있습니다.

1. SQL 프로파일 러를 사용하는 것은 까다 롭습니다. 프로파일 러를 서버에 직접 연결할 수 없으므로 일부 저장 프로 시저를 실행하여 분석 할 수있는 로그 파일을 작성해야합니다. 그것들이 어떻게 수행되는지에 대한 제안을 제공하지만 사용자 친화적은 아닙니다. 인증 된 SQL 전문가가 이러한 종류의 작업을 수행 할 것을 권장합니다.

2. Amazon이 인스턴스를 백업하는 동안 개별 데이터베이스를 복원 할 수 없습니다. 별도의 고객 별 데이터베이스가 여러 개인 웹앱이 있으며 솔루션은 운영 RDB 데이터베이스에 연결하고 데이터를 가져온 다음 EC2 인스턴스에 백업하기 위해 SQL을 실행하는 EC2 인스턴스를 시작하는 것이 었습니다. 다른 솔루션은 스키마를 다시 생성하고 데이터를 복원 지점에 다시 채우는 대규모 SQL 스크립트 (앱 서버에서)를 생성하는 타사 도구를 사용하는 것이 었습니다.

이번 주말에도 같은 질문이있었습니다. 유지 보수를 수행하는 RDS의 경우 주당 4 시간의 가동 중지 시간이 있습니다. EC2의 마이크로 인스턴스로 도망 갈 수 있다면 RDS가 더 비싸게 보였다. (이것은 최소 트래픽이있는 테스트 인스턴스에 해당합니다.) 또한 권한이 없기 때문에 RDS 인스턴스의 시간대를 변경할 수 없었습니다.

나는 실제로 다른 회사의 EC2에서 mysql 인 http://xeround.com/ 을 보고 있습니다. 그들은 InnoDB를 사용하지 않고 대신 IDG라는 자체 엔진을 가지고 있습니다. 방금 조사를 시작했지만 베타 버전으로 500MB의 공간을 제공합니다.