MySQL 용 Amazon RDS 및 Amazon EC2 인스턴스에 MySQL 설치


31

직장에서 Amazon EC2에 모든 웹 서버를 호스팅하고 일반적으로 Apache 웹 서버와 동일한 상자에 설치된 MySQL 데이터베이스를 사용하여에 통신했습니다 localhost. 이제 시스템 중 하나를 위해 데이터베이스를 자체 서버로 마이그레이션해야합니다. Amazon RDS 사용 또는 새 Amazon EC2 박스를 시작하고 MySQL을 설치 하는 두 가지 솔루션 중에서 선택할 수 있습니다.

EC2와 동일한 회사에서 제공하는 전용 데이터베이스 서비스 인 RDS는 분명히 더 나은 옵션 인 것 같습니다 . 그러나 두 가지 옵션의 가격 ( http://aws.amazon.com/ec2/pricinghttp://aws.amazon.com/rds/pricing 참조 )을 보면 RDS 서버 비용이 거의 스펙이 동일한 박스에 대해 EC2 서버의 두 배.

백업을 직접 처리 할 수 ​​있고 EC2가 RDS와 같이 인스턴스를 확장 할 수있는 동일한 기능을 제공한다는 점을 감안할 때 EC2 대신 RDS를 사용해야하는 이유는 전혀 없습니다. 비록 내가 옳다면 아무도 RDS를 사용하지 않을 것이기 때문에 아마도 큰 것을 놓친 것 같습니다. 정확히 무엇을 놓치고 EC2 인스턴스에 자체 데이터베이스를 설치하는 것보다 RDS의 장점은 무엇입니까?


이 질문을 한 이후 EC2와 RDS 간의 가격 비율이 크게 변했다는 점에 주목할 가치가 있습니다. EC2의 인스턴스 가동 시간은 여전히 ​​저렴하지만 RDS 가격의 3 분의 2 이상입니다. EC2에서 RDS로 (또는 그 반대로) 이동해도 더 이상 서버 요금이 배가되거나 절반으로 줄어들지 않습니다. (여전히 상황에 따라 신경을 쓸 가치가있을 수도 있습니다.)
Mark Amery

답변:


20

나는 일반적으로 큰 AWS 팬이지만 RDS는별로 없습니다.

@RolandoMySQLDBA는 그것에 대해 꽤 좋은 점이 지적했다.

EC2의 MySQL과 비교하여 RDS에서 볼 수있는 유일한 장점은 포인트 앤 클릭 스냅 샷, 클론 및 특정 시점 복구 기능을 수행 할 수 있다는 점이지만 제어 및 유연성 상실을 보완하기에는 충분하지 않으며 가장 높은 가격을 정당화하지는 않습니다. RDS는 어떤면에서는 섹시하지만 모든 움직이는 부분에 도달 할 수 없기 때문에 궁극적으로 고칠 수없는 것을 신뢰할 수는 없습니다.

나는 SUPER특권이 없는 것을 좋아하지 않습니다 . 오류 로그를 표시하지 못하는 것을 좋아하지 않습니다. 데이터베이스 서버에서 "top"또는 "iostat"를 실행하여 코어와 드라이브가 어떻게로드를 즐기는 지 확인하는 것을 좋아하지 않습니다. 페더레이션 스토리지 엔진에 액세스하는 것을 좋아하지 않습니다. 읽기 전용 복제본으로 활용할 수없는 핫 스텐 바이 (다중 AZ) 백업 마스터 머신에 대한 비용을 지불하는 것을 좋아하지 않습니다. 물론, MySQL을 RDBMS-in-a-box로 성공적으로 패키징하고 판매하기 위해 이러한 제약 조건을 모두 갖추어야하는 이유는 완벽하게 합리적입니다. 유일한 것은, RDBMS-in-a-box는 내가 가지고 있지 않은 일련의 문제를 "해결"하고 새로운 방식으로 문제를 일으킨다는 것입니다.

그러나 RDS를 사용하는 데있어 절대적인 문제는 바이너리 로그 및 복제에 대한 액세스가 완전히 없다는 것입니다. Binlogs, 특히 행 기반은 사소한 재난에 대한 환상적인 복구 도구이지만 액세스 할 수없는 경우 도움이되지 않습니다. 사무실의 사내 서버를 RDS에서 프로덕션 데이터베이스의 읽기 전용 복제본으로 구성하고 싶습니까? RDS에있는 데이터에 대해 생각할 수없는 일이 발생하면 로컬 백업을 수행하고보고하고 재해 복구를 위해 준비해야하는 것이 있습니까? 그것은 동시에 명백하고 화려한 아이디어입니다.

죄송합니다. 복제에 직접 액세스 할 수 없습니다. 물론, 읽기 전용 복제본에 대해서만 비용을 지불 할 수 있지만 다른 RDS 인스턴스로만 가능합니다. 내 책에 가치 제안이 아닙니다.

업데이트 : MySQL 5.6에 대한 RDS의 한 가지 중요한 변경

난 아직도, 여러 가지 이유로 RDS를 실행에 대한 지원의 부족을 포함하여 반대 (심지어 EC2에서) 내 자신의 서버를 실행 선호하는 사용자 정의 함수 는 사용할 수 없다는 연합 저장소 엔진을 , 그리고 무능력은이하는 일을 비상 접속에는 추가 연결이 가능하지만 ...

Amazon은 RDS 용 MySQL 5.6을 크게 변경하여 주요 이의 제기 중 하나를 제거했습니다. 아마도 가장 큰 이의 제기 : 이제 이진 로그에 액세스 할 수 있으며 비 RDS 인스턴스를 슬레이브로 실행하거나 다른 유틸리티를 binlog 스트림을 읽는 서버.

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html

공식적으로 문서에는 실시간 마이그레이션을 목적으로 슬레이브를 설정할 수 있도록 노출되어 있음을 나타냅니다.을 사용하여 기존 RDS 인스턴스에서 외국 미래 마스터 서버를 동기화 mysqldump한 다음 슬레이브로 RDS에 연결 응용 프로그램이 새 마스터로 마이그레이션 될 때까지 복제 스트림을 통해 업데이트를 실시간으로 제공 받지만 비공식적으로는 지원하지 않을 것으로 예상되는 한 지속적으로 업데이트 할 수 있습니다. 나에게 합리적인 것 같습니다.

이것은 최근 웹 세미나 에서 약 56:45에 시작되는 대화에서 확인 되었습니다 .

"복제 된 상태로 무기한으로 유지할 수 있습니다 ...

"... 복제를 유지할 책임이있는 한 ..."

"원하는 바에 따라 진행중인 복제를 수행 할 수 있습니다."

이 새로운 기능은 공개 웹 사이트 백업 MySQL 인스턴스에서 RDS를 사용하는 것에 대한 이의 제기를 거부하기에 충분했습니다 FEDERATED.

따라서 나는 여전히 그것을 선호하지 않지만 더 이상 반대하지 않습니다. 바이너리 로그의 실시간 스트림을 통해 실시간으로 데이터를 제어하고 트랜잭션이 없도록 보장 할 책임이 있기 때문에 더 이상 반대하지 않습니다. 나는 DBA로서 통제권을 다시 얻었 기 때문에 재난이 발생했을 때 재난이 발생했습니다. 블랙 박스 내부의 블랙홀에서 사라진 데이터를 제 3 자 공급 업체가 손가락으로 가리 키거나 소송을 제기하거나 그 밖의 것에 대해 소송을 제기하더라도 손실 된 데이터는 다시받지 않습니다.

경영진은 RDS의 "아이디어"를 좋아하고 비용 차이에 반대하지 않기 때문에 RDS가 포함 된 모든 새로운 웹 사이트를 시작합니다.

인정한 시점 및 클릭 시점 복구는 RDS의 훌륭한 기능입니다. 기존 시스템을 변경하거나 중단시키지 않고 대신 기존 백업을 사용하여 완전히 새로운 인스턴스를 생성합니다. 선택한 특정 시점에 가장 근접한 다음 필요한 binlog를 적용하여 새 시스템을 지정한 특정 시점으로 가져옵니다.

이와 관련하여, 그러나 다른 방향으로, 이제는 비슷한 전략을 사용하여 라이브 MySQL 데이터베이스를 RDS로 마이그레이션 할 수도 있습니다. RDS 마스터를 연결할 수 있습니다. RDS 인스턴스가 마이그레이션 할 때 데이터의 라이브 버전을 갖도록 기존 시스템의 슬레이브로 사용됩니다. 5.6에서만 작동하는 외부 복제를위한 RDS binlog에 대한 액세스와 달리 내부 복제는 5.5.33 및 5.6.13부터 RDS에서 지원됩니다 .


Federated Storage Engine을 어떻게 사용하는지 알고 있습니까?
Bharat Khatri

11

DB 서버 확장 이 차 한잔아닌 경우 모든 종소리와 휘파람이 함께 제공되므로 Amazon RDS를 사용해도됩니다. 중간 정도의 HA, 백업 및 스케일 아웃을 원하는 사람들은 많은 이점을 얻습니다.

반대로 하드웨어를 확장하려는 경우 RDS의 문제는 아닙니다. MySQL의 기능을 확장하려면 어떻게해야합니까? 불행히도, 그것은 많은 측면에서 바라는 바가 아닙니다.

예를 들어, 7 개의 모든 RDS 서버 모델에서 두 개의 필드가 제한되어 있다는 것을 알고 있습니까?

이 두 가지 옵션에 대한 다음 차트를 참고하십시오.

MODEL      max_connections innodb_buffer_pool_size
---------  --------------- -----------------------
t1.micro   34                326107136 (  311M)
m1-small   125              1179648000 ( 1125M,  1.097G)
m1-large   623              5882511360 ( 5610M,  5.479G)
m1-xlarge  1263            11922309120 (11370M, 11.103G)
m2-xlarge  1441            13605273600 (12975M, 12.671G)
m2-2xlarge 2900            27367833600 (26100M, 25.488G)
m2-4xlarge 5816            54892953600 (52350M, 51.123G)

당신은 제공되지 않습니다 SUPER 권한 과에 직접 액세스가있다 my.cnf. 이를 고려 my.cnf하여 시작 옵션 을 변경 하려면 먼저 MySQL 기반 DB 파라미터 옵션 목록을 생성하고를 사용 RDS CLI (Command Line Interface)하여 원하는 옵션을 변경해야합니다. 그런 다음 새 옵션을 가져 오려면이 작업을 수행해야합니다.

  • 사용자 지정 DB 파라미터 그룹 생성 (호출 MySettings)
  • RDS CLI를 다운로드하고 AWS 자격 증명으로 구성 파일을 설정하십시오.
  • 다음을 실행하십시오. ./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
  • DB 파라미터 옵션 목록을 사용하여 수정 MySettings
  • MySQL RDS 인스턴스를 다시 시작하십시오.

단일 변수를 업데이트하기 위해 API를 사용하고 RDS 인스턴스를 강제로 다시 시작하여 변경을 구현합니까? 하나의 옵션을 사용하는 것은 매우 힘든 과정입니다.

MySQL을 확장하려면 EC2를 사용하십시오. 그런 다음 my.cnf항상 해왔고 익숙한 것처럼 원하는대로 tweek 할 수 있습니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.