9
votes

Sauvegardez une base de données MySQL avec un grand nombre de tables (> 100 000)

Je sais, vraiment mauvais de base de données, mais nous sommes ici, j'ai une sorte de plate-forme forum (basée sur Punbb) et pour chaque forum, j'ai généré un nouvel ensemble de tables. Vraiment mauvaise idée.

temps est passé et maintenant j'ai plus de 100 000 tables ( show tables; Sélectionnez Found_Rows (); - - 112965 lignes en jeu (1,21 sec) ). Les performances sont excellentes car les tables font le travail d'index et lorsque vous effectuez des références directes à une table, c'est ultrafast.

Le problème est maintenant j'essaie de tout retourner et de passer à un autre serveur . Bien sûr, cela prend pour toujours. J'ai lancé un mysqldump : xxx

et il est toujours en traitement, un peu plus de 12 heures! La sauvegarde est déjà de 546 Mo de taille et MySQL est toujours en vie et travaille.

J'ai essayé de copier directement les fichiers MySQL, mais j'ai rencontré dans la question que beaucoup de tables ont été corrompues.

aucune idée de la vitesse supérieure?


6 commentaires

Y a-t-il un motif pour les noms de table? Comme un préfixe commun? aussi quel serait le total non. des rangées dans toutes les tables? Je suppose que toutes les tables ont la même structure


Il est préfixé par le nom de chaque forum. Toutes les tables avaient la même structure. Cela a été il y a quelque temps. Je ne me souviens pas de ce que j'ai terminé.


De toute évidence, il existe des compromis entre la performance et la fiabilité, donc en fonction de la RAM Votre serveur dispose, vous pouvez toujours envisager de copier les tables dans des tables en mémoire et / ou de sortir le fichier de vidage dans un fichier Ramdisk. Je envisagerais sérieusement de changer votre schéma de base de données! Il existe d'autres moyens d'optimiser les performances de MySQL, y compris le Sharding.


Quel moteur de stockage sont vos tables en utilisant?


Quelle version de mysql?


C'était il y a plus de 6 ans. Je ne me souviens pas. :) Je pense que j'ai fini par copier les fichiers MySQL. Ou attendu le 20h. Pas certain.


3 Réponses :



0
votes

Je présume du fait que vos tables sont corrompues lorsque vous copiez les fichiers que vous utilisez innoDB.

Il dit dans la documentation MySQL ici

Les outils de sauvegarde physiques incluent la sauvegarde MySQLBackup de MySQL Enterprise Sauvegarde pour Innodb ou tout autre tables ou des commandes de niveau de système de fichiers (telles que CP, SCP, TAR, RSYNC) pour les tables MyISAM.

Vous pouvez utiliser MySQL Enterprise Sauvegarde pour effectuer des sauvegardes à chauds physiques rapides, fiables et physiques (c'est-à-dire lorsque la base de données est en cours d'exécution). Je crois que c'est calme chère cependant.


0 commentaires

0
votes

À mon dernier emploi, nous avons exécuté des instances MySQL avec plus de 160 000 tables.

Avec cette quantité de tables, nous avons dû désactiver innodb_file_per_table et stocker toutes les tables dans le fichier de table central ibdata1 . Si nous ne le faisions pas, le serveur ne pouvait pas fonctionner efficacement car il avait trop de fichiers ouverts. Cela devrait être plus facile avec MySQL 8.0 mais dans l'ancienne version de MySQL que nous utilisions, le dictionnaire de données ne pouvait pas augmenter à autant de tables.

Pour faire des sauvegardes, nous avons utilisé Percona Xtrabackup . Il s'agit d'un outil open-source qui fonctionne de manière très similaire à la sauvegarde MySQL Enterprise. Il effectue une sauvegarde physique du répertoire de données, mais elle le fait sans risque de corruption de fichier que vous avez causée par la copie de fichiers directement. Percona Xtrabackup fonctionne en copiant des fichiers, mais copie également le journal des transactions INNODB continuellement, de sorte que les bits manquants des fichiers peuvent être restaurés. C'est très fiable.

Sauvegarde d'une base de données avec Percona Xtrabackup est un peu plus rapide, mais le plus grand avantage vient lorsque restaurer la sauvegarde. La restauration d'un fichier de vidage de MySqldump est très lente. Restaurer une sauvegarde physique comme celle produite par PerCona Xtrabackup peut être effectuée aussi rapidement que vous pouvez copier les fichiers de sauvegarde dans un nouveau répertoire de données, puis démarrez le serveur MySQL.

Un blog récent de Percona montre la différence:

 Entrez la description de l'image ici

HTTPS: //www.percona.com/blog/2018/04/02/migrate-a-amazon-rds-with-percona-xtrabackup/


0 commentaires