2013-08-16 9 views
6

Obecnie uruchamiamy MySQL na EC2 i jesteśmy już od jakiegoś czasu. Podoba mi się pomysł uproszczonych kopii zapasowych, odzyskiwania i przełączania awaryjnego, a mnie kusi widoczna łatwość używania RDS zamiast EC2. Rozpocząłem migrację z EC2 do RDS, ale gdy pracuję nad migracją, zastanawiam się, czy robię to, co trzeba.Dlaczego ludzie nie zalecają używania usługi Amazon RDS?

Czytałem ludzi sugerujących przeciwko korzystaniu z Amazon RDS dla baz danych MySQL, ale nie znalazłem zwięzłego wyjaśnienia wad RDS.

Czy ktoś może mi pomóc zrozumieć, dlaczego NIE powinienem przenieść się do RDS, ale zamiast tego przechowywać moje dane w EC2?

Nasza baza danych zawiera około 30 GB danych, głównie z 18-milionowej tabeli wierszy i 40-milionowej tabeli wierszy w jednej bazie danych InnoDB.

Wszelkie przemyślenia są mile widziane. Dzięki!

+1

Podczas gdy zyskujesz trochę automatyzacji, tracisz kontrolę. Jest to kompromis, który nie jest wart dla wszystkich. – datasage

Odpowiedz

0

Jedyną rzeczą, której można by się pozbyć za pomocą RDS, są dzienniki, niestety RDS nie udostępnia pełnego zestawu dzienników, które są niekiedy niezbędne do debugowania. Jeśli możesz żyć bez nich i masz silne testy przed przejściem do produkcji, to RDS jest drogą do zrobienia.

+3

Myślę, że to się zmieniło: http://aws.amazon.com/about-aws/whats-new/2013/03/04/amazon-rds-db-log-access/ –

3

Jest to głównie problem z DBA zespołu.

RDS ma na celu usunięcie większości powtarzających się i nudnych zadań DBA (głównie replikacja wielu AZ, tworzenie kopii zapasowych, przywracanie, łatanie ...). Ta część może stanowić nawet 70% czasu spędzanego przez administratorów baz danych.

Z drugiej strony niektóre zadania, które może wykonywać DBA, jeśli korzystają z bazy danych na swojej instancji (na przykład w EC2), nie są dostępne z RDS, ponieważ nie mają ROOT w instancji RDS.

Jeśli twój DBA (i twój przypadek użycia) może skorzystać z ciężkiego podnoszenia i nie cierpieć z powodu ograniczonych przywilejów, powinieneś wziąć pod uwagę RDS.

+0

W tym przypadku jestem programista i DBA. Chociaż nie jestem administratorem DBA w pełnym wymiarze godzin i nie jest to moja najlepsza wiedza, nie mam doświadczenia w administracji MySQL. Próbuję dowiedzieć się, o jakich rzeczach nie myślę teraz, co może później zahamować moje umiejętności. –

+1

Potem sugeruję, żebyś to zrobił. Jestem również jedynym rezydentem sysadmin i wolałbym outsourcować kluczowe, ale nużące zadania DBA, gdzie mogę.Nie udało mi się jeszcze rozwiązać problemu, w którym brak pełnego dostępu do roota był problemem, ale wiele rozproszenia (i stresu) zniknęło dzięki backupom, przełączaniu awaryjnemu, zarządzaniu pojemnością i aktualizacjami zarządzanymi przez RDS. To nie jest tak, że jest to decyzja typu "umrzyj" lub "umrzyj": jeśli znajdziesz coś później, czego nie możesz zrobić, możesz zawsze odpalić swoje własne pole MySQL ponownie. Założę się, że nie będziesz tego potrzebować. – ianjs

+0

RDS jest niesamowity - https://www.youtube.com/watch?v=RwCn5KAiFqM –

3

Zarządzamy bazą danych 200 GB w dwudziestu tabelach w RDS. Z mojego doświadczenia wynika, że ​​używanie RDS oszczędza mnóstwo czasu, a istniejące wady są niewielkie i można je obejść. Ogólnie, czas, jaki RDS zaoszczędził, jest znacznie większy niż ten, który przynosi ból głowy. Jednakże, dwa, że ​​miałem do czynienia to:

  1. Nie można ustawić zmienne globalne jako użytkownik root w RDS trzeba ustawić je w parameter group a następnie zastosować że do bazy danych, co jest trudniejsze niż "SET GLOBAL", ale oferuje inne korzyści.

  2. Nie można zrzucić do pliku wyjściowego, ponieważ nie masz dostępu do systemu plików RDS. Zobacz this question. Jednak, jak zaznaczono w tym pytaniu, istnieją rozwiązania.

Powiązane problemy