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.