Dlaczego ten problem wystąpił, mimo że wolumen pamięci masowej Amazon Aurora automatycznie wzrośnie do 64 TB.?
Najpierw zrozumiemy przechowywanie w RDS Aurora. W Aurorze są 2 rodzaje przechowywania. Sklep z instancjami to pamięć lokalna, w której przechowywane są obiekty tymczasowe, a pamięć główna dla danych. Dlatego po uruchomieniu ALTER na tabeli wygeneruje ona tabelę tymczasową, a aurora RDS użyje magazynu instancji do przechowywania tabeli tymczasowej. W przypadku Twojej instancji, która jest instancją db.r3.large, ma ona 1 × 32 GB pamięci lokalnej, więc jeśli obiekty tymczasowe w instancji staną się większe niż ten rozmiar, pojawi się błąd „tabela pełna”. Ponadto lokalny limit pamięci różni się od całkowitej objętości pamięci dostępne dla Twojej instancji Aurora, a na podstawie wykorzystania Twojej bazy danych wolumen pamięci masowej Amazon Aurora będzie automatycznie powiększał się do 64 TB w przyrostach co 10 GB.Zmień na dużym stole w RDS rozwiązanie pełnej tabeli Błąd
- Aby rozwiązać ten problem, możesz przeskalować instancję w górę, aby uzyskać więcej lokalnej pamięci do uruchomienia ALTER, zmienić tabelę, a następnie zmniejszyć typ instancji. Skutkuje to pewnymi przestojami podczas aktualizacji/zniżania typu instancji.
- Możesz również użyć polecenia:„pt-online-schema-change”, jeśli użyjesz tego polecenia, oryginalna tabela będzie nadal dostępna do użytku bez przestojów lub bez blokady stołu.
Wyniki:
Jeśli zmieniasz tabelę za pomocą pt -zmiana-schematu online polecenie na stół, który ma rozmiar 35-40 GB, może zająć około 30 godzin.pt-online-zmiana-schematu nie blokuje stołu. To polecenie tworzy wyzwalacze w oryginalnej tabeli. Ale do tego potrzebne są uprawnienia superużytkownika. podczas korzystania z procedury przechowywania pojawi się błąd:Dlaczego używać polecenia pt-online-schema-change i dlaczego włączyć „log_bin_trust_function_creators” w grupie parametrów DB? ?
#1419 – Nie masz uprawnień SUPER, a logowanie binarne jest włączone (*możesz* użyć mniej bezpiecznej zmiennej log_bin_trust_function_creatorsPowód: Ten błąd występuje w instancjach RDS, gdy próbujesz użyć „Procedury składowane”. Wkrótce dowiesz się, że przyznanie super przywileju użytkownikowi nie zadziała. Jedynym sposobem, aby wszystko działało, jest ustawienie log_bin_trust_function_creators na 1. Zgodnie z dokumentami Percony: Najważniejsze jest to, że tworzenie wyzwalaczy na serwerze z włączonymi logami binarnymi wymaga użytkownika z uprawnieniami SUPER (co jest niemożliwe w Amazon RDS). Komunikat o błędzie określa obejście. Musimy włączyć zmienną w grupie parametrów DB „log_bin_trust_function_creators”. Włączenie tego jest jak powiedzenie serwerowi: „Ufam wyzwalaczom i funkcjom zwykłych użytkowników i że nie spowodują one problemów, więc pozwól moim użytkownikom je tworzyć”. Ponieważ funkcjonalność bazy danych się nie zmieni, staje się kwestią zaufania użytkownikom. log_bin_trust_function_creators to zmienna globalna, którą można zmieniać dynamicznie. Próbuję znaleźć więcej szczegółów na temat „Super_priv”, Kiedy sprawdzasz uprawnienia użytkowników w tabeli użytkowników bazy danych MySQL. widać, że Super_priv nie jest ustawiony dla nikogo poza użytkownikiem rdsadmin.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Tutaj „root” to użytkownik główny, a „dbuser” to użytkownik DB, których ci użytkownicy są stworzeni przez nas, a użytkownik „rdsadmin” jest automatycznie tworzony przez AWS, do którego nie mamy dostępu. Użytkownik rdsadmin MySQL jest używany przez Amazon do prac konserwacyjnych i zarządczych.
To jest koniec samouczka, jak zmienić duży stół w rozwiązaniu RDS, aby uzyskać pełny błąd tabeli.
