W pracy hostujemy wszystkie nasze serwery na Amazon EC2 i zwykle korzystaliśmy z baz danych MySQL zainstalowanych na tym samym urządzeniu co nasz serwer Apache i komunikowaliśmy się z nimi localhost. Teraz stajemy przed potrzebą migracji naszej bazy danych na własny serwer dla jednego z naszych systemów. Mam wybór między dwoma rozwiązaniami: użyj Amazon RDS lub po prostu uruchom nowe urządzenie Amazon EC2 i zainstaluj na nim MySQL.

RDS, będący dedykowaną usługą bazy danych świadczoną przez tę samą firmę co EC2, wydaje się być zdecydowanie lepszą opcją. Jednak patrząc na ceny dwóch opcji (patrz http://aws.amazon.com/ec2/pricing i http://aws.amazon.com/rds/pricing ) wydaje się, że serwer RDS kosztuje prawie dwa razy więcej niż serwer EC2 dla urządzenia o tej samej specyfikacji.

Biorąc pod uwagę, że jestem w stanie samodzielnie obsługiwać kopie zapasowe i że EC2 oferuje taką samą możliwość skalowania instancji, jak wymaga tego RDS, nie widzę żadnego powodu, aby używać RDS zamiast EC2. Wygląda na to, że prawdopodobnie brakuje mi czegoś dużego, ponieważ gdybym miał rację, nikt nie używałby RDS. Czego dokładnie brakuje i jakie są zalety RDS w porównaniu z instalacją własnej bazy danych w instancji EC2?

Ogólnie jestem wielkim fanem AWS ... ale nie RDS.

@RolandoMySQLDBA wskazał, że istnieją przeciwko temu całkiem dobre punkty.

Jedyną zaletą, którą widzę w RDS w porównaniu z MySQL na EC2, jest możliwość wykonywania migawek „wskaż i kliknij”, klonów i odzyskiwania w określonym momencie, ale nie są one wystarczające, aby zrekompensować utratę kontroli i elastyczności, a także z pewnością nie uzasadniają wyższej ceny. RDS jest pod pewnymi względami seksowny, ale ostatecznie nie możesz ufać temu, czego nie możesz ostatecznie naprawić, ponieważ nie możesz dostać się do wszystkich ruchomych części.

Nie lubię nie mieć tego SUPERprzywileju. Nie podoba mi się to, że nie mogę dostosować dziennika błędów. Nie lubię nie być w stanie uruchomić „top” lub „iostat” na moim serwerze bazy danych, aby zobaczyć, jak rdzenie i dyski cieszą się z obciążenia. Nie lubię nie mieć dostępu do stowarzyszonego silnika pamięci masowej. Nie podoba mi się myśl, że zapłacę za gorącą rezerwową maszynę główną (multi-AZ), której nie mogę nawet wykorzystać jako repliki odczytu. Jasne, istnieją całkowicie uzasadnione wyjaśnienia, dlaczego wszystkie te ograniczenia muszą istnieć, aby MySQL został pomyślnie spakowany i sprzedany jako RDBMS-in-a-box. Jedyną rzeczą jest to, że RDBMS-in-a-box „rozwiązuje” całą serię problemów, których nie mam ... i przeszkadza , powodując nowe problemy.

Ale dla mnie absolutnym przełomem w RDS jest całkowity brak dostępu do binarnych logów i replikacji. Binlogi, zwłaszcza oparte na wierszach, są fantastycznym narzędziem do odzyskiwania w przypadku drobnych katastrof, ale nie są pomocne, jeśli nie możesz uzyskać do nich dostępu. Chcesz skonfigurować lokalny serwer w swoim biurze jako replikę do odczytu produkcyjnej bazy danych w RDS? Coś, z czego można wziąć lokalne kopie zapasowe, zrobić raportowanie, mieć pod ręką do odzyskiwania po awarii, czy coś nieoczekiwanego stanie się z danymi przechowywanymi w RDS? To pomysł, który jest jednocześnie oczywisty i genialny.

Niestety, bezpośredni dostęp do replikacji nie jest dostępny. Jasne, możesz zapłacić za repliki odczytu ... ale tylko tak, jak inne instancje RDS. W mojej książce nie jest to propozycja wartości.

Aktualizacja: Jedna znacząca zmiana w RDS dla MySQL 5.6

Nadal wolę uruchamiać własny serwer (nawet w EC2) niż RDS z wielu powodów, w tym braku wsparcia dla funkcji zdefiniowanych przez użytkownika , niemożności korzystania z Federated Engine Engine i niemożności posiadania jednego dostępne dodatkowe połączenie dla dostępu awaryjnego ... jednak ...

Amazon dokonał znaczącej zmiany w MySQL 5.6 dla RDS, która eliminuje jeden z moich głównych zastrzeżeń - być może mój największy sprzeciw: dzienniki binarne są teraz dostępne i możesz uruchomić instancję inną niż RDS jako slave lub podłączyć inne narzędzia do serwer, który czyta strumień binlog.

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

Oficjalnie dokumentacja wskazuje, że ujawniają to, dzięki czemu można skonfigurować urządzenie podrzędne w celu przeprowadzenia migracji na żywo - synchronizujesz zagraniczny przyszły serwer główny z istniejącą instancją RDS za pomocą mysqldump, a następnie podłączasz go do RDS jako urządzenie podrzędne aby otrzymywać bieżący kanał aktualizacji za pośrednictwem strumienia replikacji, dopóki aplikacja nie zostanie migrowana do nowego wzorca - ale nieoficjalnie możesz to robić na bieżąco, o ile nie oczekujesz, że będą cię wspierać ... co, wydaje mi się rozsądne.

Zostało to potwierdzone podczas ostatniego seminarium internetowego w rozmowie, która rozpoczyna się około 56:45:

„Możesz utrzymywać go w stanie replikacji przez czas nieokreślony ...

„... tak długo, jak bierzesz odpowiedzialność za utrzymanie replikacji ...”

„Nie przeszkadzamy w wykonywaniu ciągłej replikacji, jeśli tego właśnie chcesz”.

Ta nowa funkcja wystarczyła mi, by porzucić mój ogólny sprzeciw wobec używania RDS w naszych publicznych instancjach MySQL wspierających stronę internetową, w których nie używamy FEDERATEDlub niektórych innych rzeczy tak często lub wcale.

Wciąż nie jestem zwolennikiem tego, ale nie jestem już temu przeciwny, ponieważ posiadanie strumienia dzienników binarnych na żywo pozwala mi ostatecznie kontrolować dane w czasie rzeczywistym i jestem odpowiedzialny za to, aby żadne transakcje nie były zagubiony w katastrofalnej awarii wraca ze mną, ponieważ ja, jako DBA, odzyskuję kontrolę - dokładnie tego chcę. Posiadanie zewnętrznego dostawcy, aby wskazał palcem, wytoczył proces lub cokolwiek innego, nie odzyska utraconych danych, jeśli zniknie w czarnej dziurze w czarnej skrzynce.

Wydaje się, że zarządowi podoba się „pomysł” RDS i nie sprzeciwia się różnicy kosztów, dlatego teraz uruchamiamy wszystkie nowe strony internetowe z RDS za nimi.

Przyznaję, że odzyskiwanie punktowe w czasie jest przyjemne w RDS ... nie zmienia ani nie zakłóca istniejącej maszyny - zamiast tego uruchamia zupełnie nową instancję, używając kopii zapasowej, która była najbliżej wybranego punktu w czasie, a następnie stosuje niezbędne dzienniki binlogów, aby przenieść tę nową maszynę do określonego momentu.

W związku z tym, ale w innym kierunku, teraz można również zastosować podobną strategię do migracji bazy danych MySQL na żywo do RDS ... możesz podłączyć master RDS (przypuszczalnie zazwyczaj byłby to nowo wdrożony wystąpienie) jako element podrzędny istniejącego systemu, tak aby wystąpienie RDS miało bieżącą wersję danych w momencie migracji do niego. W przeciwieństwie do dostępu do binlogów RDS dla zewnętrznej replikacji, która działa tylko w 5.6, replikacja wewnętrzna jest obsługiwana w RDS począwszy od 5.5.33 i 5.6.13.

Jeśli skalowanie serwerów DB nie jest twoją filiżanką herbaty , możesz użyć Amazon RDS, ponieważ wszystkie dzwonki i gwizdki są z tym związane. Ci, którzy po prostu chcą umiarkowanego HA, kopii zapasowych i skalowania, czerpią ogromne korzyści.

Z drugiej strony, jeśli chcesz skalować sprzęt, nie ma mowy o RDS. Co jeśli chcesz zwiększyć możliwości MySQL? Niestety jest to wykluczone z wielu powodów.

Na przykład, czy wiesz, że dwa pola są ograniczone do wszystkich siedmiu (7) modeli serwerów RDS?

• max_connections
• innodb_buffer_pool_size

Zwróć uwagę na poniższą tabelę dotyczącą tych dwóch opcji:

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)

Nie masz uprawnienia SUPER i nie masz bezpośredniego dostępu do niego my.cnf. W świetle tego, aby zmienić my.cnfopcje uruchamiania, musisz najpierw utworzyć listę opcji parametrów DB opartą na MySQL i użyć RDS CLI (Command Line Interface)do zmiany żądanych opcji. Następnie musisz to zrobić, aby zaimportować nowe opcje:

• Utwórz niestandardową grupę parametrów DB (nazwij ją MySettings)
• Pobierz interfejs RDS CLI i skonfiguruj plik konfiguracyjny przy użyciu poświadczeń AWS
• Wykonaj następujące czynności: ./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
• Zmodyfikuj za pomocą listy opcji parametrów DB MySettings
• Uruchom ponownie instancję MySQL RDS

Używasz interfejsu API do aktualizacji pojedynczej zmiennej i obowiązkowego ponownego uruchomienia instancji RDS w celu wdrożenia zmiany? To dość bolesny proces, aby podkręcić dowolną opcję.

Jeśli chcesz skalować MySQL, użyj EC2. Następnie możesz dostosować my.cnfdo swoich upodobań, tak jak zawsze robiłeś to i byłeś przyzwyczajony.