it-swarm-eu.dev

Amazon RDS pro MySQL vs instalace MySQL na instanci Amazon EC2

V práci hostujeme všechny naše webové servery na Amazonu EC2 a obvykle jsme používali databáze MySQL nainstalované ve stejné krabici jako náš webový server Apache a s nimi jsme komunikovali na localhost. Nyní čelíme potřebě migrovat naši databázi na vlastní server pro jeden z našich systémů. Mám na výběr mezi dvěma řešeními: použijte Amazon RDS , nebo jen spusťte nový Amazon EC2 a nainstalujte do něj MySQL.

RDS, která je vyhrazenou databázovou službou poskytovanou stejnou společností jako EC2, vypadá, že by měla být zjevně lepší možnost. Když se však podívám na stanovení cen pro obě možnosti (viz http://aws.Amazon.com/ec2/pricing a http://aws.Amazon.com/rds)/price ) Zdá se, že RDS server stojí téměř dvakrát tolik jako server EC2 za krabici se stejnými specifikacemi.

Vzhledem k tomu, že jsem schopen zpracovat zálohy sám a že EC2 nabízí stejnou schopnost zvětšit instanci, jak vyžaduje RDS, nevidím žádný důvod k použití RDS místo EC2. Vypadá to, že mi asi chybí něco velkého, protože kdybych měl pravdu, nikdo by RDS nepoužíval. Co přesně mi chybí a jaké jsou výhody RDS oproti instalaci vlastní databáze na instanci EC2?

31
Mark Amery

Jsem velký fanoušek AWS obecně ... ale RDS, ne tolik.

Uživatel @RolandoMySQLDBA poukázal na některé docela dobré body.

Jedinou výhodu, kterou vidím v RDS ve srovnání s MySQL na EC2, je schopnost vytvářet snímky typu point and click, klony a point-in-time zotavení, ale tyto nejsou dostačující pro vyrovnání ztráty kontroly a flexibility a oni určitě neospravedlňují vyšší cenu. RDS je v některých ohledech sexy, ale nakonec nemůžete věřit tomu, co nemůžete nakonec opravit, protože se nemůžete dostat ke všem pohyblivým částem.

Nemám ráda oprávnění SUPER. Nelíbí se mi, že nedokážu sledovat protokol chyb. Nelíbí se mi, že na svém databázovém serveru nemůžu spustit „top“ nebo „iostat“, abych viděl, jak si jádra a jednotky užívají zátěž. Nemám rád přístup k federovanému úložišti. Nelíbí se mi myšlenka platit za hot standyby (multi-AZ) záložní hlavní stroj, který nemůžu využít jako přečtenou repliku. Jistě, existují naprosto rozumná vysvětlení, proč musí být všechna tato omezení zavedena, aby bylo MySQL úspěšně zabaleno a prodáno jako RDBMS v krabici. Jediná věc je, že RDBMS-in-a-box "řeší" celou řadu problémů, které nemám ... a dostane se do mých způsobuje nové problémy.

Absolutním řešením pro mě s RDS je ale naprostý nedostatek přístupu k binárním protokolům a replikaci. Binlogy, zejména řádkové, jsou fantastickým nástrojem pro obnovu menších katastrof, ale pokud k nim nemáte přístup, nepomohou vám. Chcete nakonfigurovat server ve vaší kanceláři jako repliku čtení vaší produkční databáze v RDS? Něco, z čeho lze vzít místní zálohy, mají hlášení, mít po ruce zotavení po katastrofě by se vašim datům, která žijí v RDS, mělo stát něco nemyslitelného? To je myšlenka, která je současně zřejmá a brilantní.

Jejda, je nám líto, přímý přístup k replikaci není k dispozici. Určitě můžete zaplatit za přečtené repliky ... ale pouze jako ostatní instance RDS. V mé knize není návrh hodnot.

Aktualizace: Jedna významná změna v RDS pro MySQL 5.6

Pořád dávám přednost spuštění vlastního serveru (i v EC2), oproti spuštění RDS z mnoha důvodů, včetně nedostatečné podpory pro funkce definované uživatelem , nemožnosti použít Federated Storage Engine a neschopnost mít jedno zvláštní připojení k dispozici pro nouzový přístup ... nicméně ...

Amazon provedl významnou změnu v MySQL 5.6 pro RDS, která vylučuje jednu z mých hlavních námitek - snad moje největší námitka: binární protokoly jsou nyní přístupné a můžete spustit non-RDS instanci jako otrok nebo připojit další nástroje k server, který čte datový proud binlogu.

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

Dokumentace oficiálně uvádí, že to odhaluje, takže můžete nastavit podřízeného za účelem provedení živé migrace - synchronizujete budoucí budoucí hlavní server z existující instance RDS pomocí mysqldump, poté se připojte do RDS jako otrok získáte živý přenos aktualizací prostřednictvím replikačního proudu, dokud vaše aplikace nebude migrována na nového mastera - ale neoficiálně to můžete dělat průběžně, pokud neočekáváte, že budou podporovat ty ... což se mi zdá rozumné.

Toto bylo potvrzeno v nedávném Webinar , v konverzaci, která začíná kolem 56:45:

"Můžeš to udržet v replikovaném stavu na neurčito ...".

"... pokud vezmete odpovědnost za udržování replikace ..."

"Nebráníme vám v tom, abyste pokračovali v replikaci, pokud to chcete."

Tato nová schopnost mi stačila k tomu, abych upustil od své plošné námitky proti používání RDS v našich veřejných MySQL instancích podporujících webové stránky, kde nepoužíváme FEDERATED nebo některé z dalších věcí tolik nebo vůbec.

Stále tedy nejsem pro to, ale už jsem proti tomu, protože mít živý proud binárních protokolů mě v konečném důsledku zpětně kontroluje nad daty a odpovídá za to, že žádné transakce nejsou ztracená při katastrofickém výpadku je zpět se mnou, protože já, jako DBA, jsem zpět pod kontrolou - přesně to chci. Pokud dodavatel třetí strany nasměruje prsty nebo podá žalobu nebo cokoli jiného, ​​neztratí zpět vaše ztracená data, pokud zmizí v černé díře uvnitř černé skříňky.

Zdá se, že management má rád „myšlenku“ společnosti RDS a nemá námitky proti rozdílům v nákladech, takže nyní spouštíme všechny nové webové stránky s RDS za nimi.

Přiznávám, že bodové a klikové obnovení v čase je v RDS pěknou funkcí ... nemění ani nenarušuje váš stávající počítač - místo toho spouští zcela novou instanci pomocí zálohy, která byla nejblíže k vybranému bodu v čase a poté použije potřebné blogy, aby posunul tento nový stroj dopředu k určenému časovému bodu.

S tím souvisí, ale v opačném směru je také možné, nyní, použít podobnou strategii pro migraci živé databáze MySQL do RDS ... můžete připojit master RDS (pravděpodobně to obvykle bude nově nasazený) instance) jako otrok existujícího systému, takže instance RDS má v okamžiku, kdy do něj migrujete, živou verzi dat. Na rozdíl od přístupu k RDS binlogům pro vnější replikaci, která funguje pouze v 5.6, vnitřní RDS je v RDS podporována začínající 5.5.33 a 5.6.13.

20
Michael - sqlbot

Pokud je škálování DB serverů ne váš šálek čaje , pak je Amazon RDS v pořádku, protože s tím přicházejí všechny zvonky a píšťalky. Ti, kteří prostě chtějí umírnit HA, zálohy a škálování, mají velký prospěch.

Na druhou stranu, pokud chcete rozšířit hardware, to není pro RDS vyloučeno. Co když chcete rozšířit možnosti MySQL? To bohužel není možné z mnoha hledisek.

Věděli jste například, že ve všech sedmi (7) modelech RDS jsou omezena dvě pole?

Vezměte na vědomí následující graf na tyto dvě možnosti:

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)

Není vám uděleno SUPER oprávnění a neexistuje přímý přístup k my.cnf. S ohledem na to, abyste mohli změnit možnosti spuštění my.cnf, Musíte nejprve vytvořit seznam možností parametrů DB založený na MySQL a pomocí funkce RDS CLI (Command Line Interface) změnit požadované možnosti. Poté musíte provést import nových možností:

  • Vytvoření vlastní skupiny parametrů DB (volejte MySettings)
  • Stáhněte si RDS CLI a nastavte konfigurační soubor pomocí svých pověření AWS
  • Proveďte následující: ./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
  • Upravit pomocí seznamu možností parametrů DB MySettings
  • Restartujte MySQL RDS Instance

Používáte rozhraní API pro aktualizaci jedné proměnné a provádění povinného restartování instance RDS k provedení změny? Je to docela bolestivý proces, jak zkrotit jednu možnost.

Pokud chcete rozšířit MySQL, použijte EC2. Potom můžete my.cnf Poklepat podle svých představ, jako jste to vždycky dělali a na co jste byli zvyklí.

11
RolandoMySQLDBA