Първо, ще разберем съхранението в RDS Aurora. Има 2 вида съхранение в Aurora. Съхранение на екземпляри е локално хранилище, където се съхраняват временни обекти и основното хранилище за данни. Следователно, когато стартирате ALTER на таблица, той ще генерира временна таблица и RDS aurora ще използва хранилище на екземпляри за съхраняване на временната таблица. За вашия екземпляр, който е db.r3.large екземпляр, той има 1×32 GB локално хранилище, така че ако вашите временни обекти в екземпляра станат по-големи от този размер, получавате грешка „пълна таблица“. Освен това ограничението за локално хранилище е различно от общия обем на съхранение наличен за вашия екземпляр на Aurora и въз основа на използването на вашата база данни обемът ви за съхранение на Amazon Aurora автоматично ще нараства до 64 TB на стъпки от 10 GB.Защо възникна този проблем, въпреки че обемът за съхранение на Amazon Aurora автоматично ще нарасне до 64TB.?
Промяна на голяма маса в RDS решение на пълната таблица Грешка
- За да преодолеете проблема, можете да увеличите екземпляра, за да получите повече локално хранилище, за да стартирате вашия ALTER, да промените таблицата и след това да намалите типа на екземпляра. Това води до известно време на престой при надграждане/понижаване на типа на екземпляра.
- Можете също да използвате:командата “pt-online-schema-change”, ако използвате тази команда, тя прави оригиналната таблица все още достъпна за използване без прекъсване или без заключване на масата.
Резултати:
Ако променяте таблицата с pt -online-schema-change команда на таблица с размер 35-40GB, тогава може да отнеме около 30 часа.pt-online-schema-change не заключва масата. Тази команда създава тригери в оригиналната таблица. Но за това се нуждае от привилегии на суперпотребител. когато използвате процедура за съхранение, ще получите грешката:Защо да използвате команда pt-online-schema-change и защо да активирате “log_bin_trust_function_creators “ в групата параметри на DB? ?
#1419 – Нямате привилегията SUPER и двоичното регистриране е активирано (може би *може да искате да използвате по-малко безопасната променлива log_bin_trust_function_creatorsПричина: Тази грешка възниква в RDS екземпляри, когато се опитате да използвате „Съхранени процедури“. Скоро ще разберете, че предоставянето на супер привилегия за потребител няма да работи. Така че единственият начин да накарате нещата да работят е да зададете log_bin_trust_function_creators на 1. Съгласно документите на Percona: В крайна сметка създаването на тригери на сървър с активирани двоични регистрационни файлове изисква потребител със СУПЕР привилегии (което е невъзможно в Amazon RDS). Съобщението за грешка указва заобикалянето. Трябва да активираме променливата в групата параметри на DB „log_bin_trust_function_creators“. Активирането му е като да кажете на сървъра: „Доверявам се на тригерите и функциите на обикновените потребители и че те няма да създават проблеми, така че позволете на потребителите ми да ги създават.“ Тъй като функционалността на базата данни няма да се промени, става въпрос за доверие на вашите потребители. log_bin_trust_function_creators е глобална променлива, която може да се променя динамично. Опитвам се да намеря повече подробности за „Super_priv“, Когато проверите разрешенията на потребителите в потребителската таблица на MySQL базата данни. можете да видите, че Super_priv не е зададен за никого освен за потребителя rdsadmin.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Тук „root“ е главният потребител, а „dbuser“ е потребителят на DB, тези потребители са създадени от нас, а потребителят „rdsadmin“ се създава автоматично от AWS, до който ние нямаме достъп до този потребител. rdsadmin MySQL потребителят се използва от Amazon за работа по поддръжка и управление.
Това е краят на урока как да промените голяма маса в RDS Solution към пълна грешка на масата.
