Database
 sql >> Base de données >  >> RDS >> Database

Alter on Big Table in RDS Solution to table full Error

Modifier sur Big Table dans RDS Solution au tableau plein Erreur. Prenons un exemple :des tables de très grande taille (~> 100 Go à 600 Go). Faire des modifications sur de si grandes tables est une tâche gourmande en mémoire et en CPU. Lorsque vous essayez de modifier la requête sur l'une des tables, cela donne "ERROR 1114 (HY000):table full ” erreur…

Pourquoi ce problème s'est-il produit alors que le volume de stockage d'Amazon Aurora augmentera automatiquement jusqu'à 64 To ?

Tout d'abord, nous allons comprendre le stockage dans RDS Aurora. Il existe 2 types de stockage dans Aurora. Magasin d'instances est le stockage local où les objets temporaires sont stockés et le stockage principal pour les données. Par conséquent, lorsque vous exécutez ALTER sur une table, il générera une table temporaire et RDS Aurora utilisera le stockage d'instance pour stocker la table temporaire. Pour votre instance qui est l'instance db.r3.large, elle dispose de 1 × 32 Go de stockage local. Par conséquent, si vos objets temporaires sur l'instance deviennent plus grands que cette taille, vous obtenez l'erreur "table pleine". De plus, la limite de stockage local est différente du volume de stockage total disponible pour votre instance Aurora et en fonction de l'utilisation de votre base de données, votre volume de stockage Amazon Aurora augmentera automatiquement, jusqu'à 64 To, par incréments de 10 Go.

Modifier sur une grande table en RDS  solution à l'erreur table pleine

  1. Pour surmonter le problème, vous pouvez faire évoluer l'instance afin d'obtenir plus de stockage local pour exécuter votre ALTER, modifier la table, puis réduire le type d'instance. Cela entraîne des temps d'arrêt pendant la mise à niveau/rétrogradation du type d'instance.
  2. Vous pouvez également utiliser :la commande "pt-online-schema-change", si vous utilisez cette commande, la table d'origine reste disponible sans interruption ou pas de verrouillage de table.
Si vous ne pouviez pas vous permettre d'avoir un temps d'arrêt dans le système, utilisez la commande pt-online-schema-change au lieu de mettre à l'échelle l'instance. Cependant, la documentation de pt-online-schema-change  dit, nous devrions faire une sauvegarde avant d'exécuter cette commande. Par conséquent, pour éviter tout verrouillage de table et tout échec lors du changement de table de production, vous pouvez tester cette commande sur une copie exacte de la base de données de l'application, avec le même type d'instance RDS. Essayez également d'ajouter une charge d'écriture importante sur la table pour imiter le trafic . Pour ce faire, créez un script bash qui insère en permanence une nouvelle ligne dans la table. Pour obtenir rapidement une copie exacte de votre base de données actuelle, prenez un instantané de la base de données RDS et restaurez-le à partir de l'instantané à des fins de test.  Avant d'exécuter cette commande, nous devons définir log_bin_trust_function_creators sur 1 dans le groupe de paramètres RDS DB. Une fois que vous avez terminé avec le processus ALTER, vous pouvez redéfinir la variable sur "0".
Résultats :
Si vous modifiez le tableau avec pt -online-schema-change  commande sur  une table d'une taille de 35 à 40 Go, cela peut prendre environ 30 heures.

Pourquoi utiliser la commande pt-online-schema-change et pourquoi l'activer  "log_bin_trust_function_creators "  dans le groupe de paramètres de base de données ?  ?

pt-online-schema-change  ne verrouille pas la table. Cette commande crée des déclencheurs sur la table d'origine. Mais pour cela, il a besoin de privilèges de superutilisateur. lorsque vous utilisez la procédure de magasin, vous obtiendrez l'erreur :
#1419 - Vous n'avez pas le privilège SUPER et la journalisation binaire est activée (vous *pourriez* vouloir utiliser la variable moins sûre log_bin_trust_function_creators
Raison :  Cette erreur se produit sur les instances RDS lorsque vous essayez d'utiliser des "procédures stockées". Vous découvrirez bientôt que l'octroi du super privilège à un utilisateur ne fonctionnera pas. Ainsi, la seule façon de faire fonctionner les choses est de définir log_bin_trust_function_creators sur 1.   Selon les documents Percona : L'essentiel est que la création de déclencheurs sur un serveur avec des journaux binaires activés nécessite un utilisateur avec des privilèges SUPER (ce qui est impossible dans Amazon RDS). Le message d'erreur spécifie la solution de contournement. Nous devons activer la variable dans le groupe de paramètres DB "log_bin_trust_function_creators". L'activer revient à dire au serveur : "Je fais confiance aux déclencheurs et aux fonctions des utilisateurs réguliers, et qu'ils ne causeront pas de problèmes, alors permettez à mes utilisateurs de les créer." Étant donné que la fonctionnalité de la base de données ne changera pas, il s'agit de faire confiance à vos utilisateurs. log_bin_trust_function_creators est une variable globale qui peut être modifiée dynamiquement. Essayer de trouver plus de détails sur "Super_priv", Lorsque vous vérifiez les autorisations des utilisateurs dans la table des utilisateurs de la base de données MySQL. vous pouvez voir que le Super_priv n'est défini pour personne d'autre que l'utilisateur rdsadmin. 
MySQL> select User,Super_priv from user;
+-----------+------------+
| User | Super_priv |
+-----------+------------+
| rdsadmin | Y |
| root | N |
| dbuser | N |
+-----------+------------+
3 rows in set (0.00 sec)

Ici, "root" est l'utilisateur maître et "dbuser" est l'utilisateur DB, ces utilisateurs sont créés par nous et l'utilisateur "rdsadmin" est automatiquement créé par AWS auquel nous n'avons pas accès. L'utilisateur MySQL rdsadmin est utilisé par Amazon pour les travaux de maintenance et de gestion.

Ceci est la fin du didacticiel, comment modifier sur Big Table dans la solution RDS pour tabler une erreur complète.