J'ai dû faire un peu de fouille dans le code source de mydumper pour trouver la réponse à cette question. Si vous regardez le code source réel de mydumper:
Vous trouverez les éléments suivants à partir de la ligne 415 dans le cadre de la file d'attente de processus:
if(use_savepoints && mysql_query(thrconn, "SET SQL_LOG_BIN = 0")){
g_critical("Failed to disable binlog for the thread: %s",mysql_error(thrconn));
exit(EXIT_FAILURE);
}
Cela montre que l'utilisation de --use-savepoints dans mydumper nécessite la possibilité de désactiver le journal de bin MySQL. J'ai tenté cela sur mon propre serveur MariaDB qui utilise toujours MySQL comme SGBD de base et j'ai obtenu l'erreur suivante lors de l'utilisation d'un compte non administrateur:
MariaDB [(aucun)]> SET SQL_LOG_BIN = 0; ERREUR 1227 (42000): accès refusé; vous avez besoin (au moins un des) privilège (s) SUPER pour cette opération
D'après ce que je lisais du code réel et testais cette condition sur mon propre serveur MySQL, je comprends que vous avez besoin de "privilège SUPER" car mydumper désactivera la journalisation dans le binlog pendant son exécution. Cela fait partie de la puissance "d'activation ou de désactivation de la journalisation" d'un SUPER mentionnée dans le DOCS .
Des informations plus spécifiques sur le binlog sont ici:
http://dev.mysql.com/doc/refman/5.6/en/set-sql-log-bin.html
En ce qui concerne les points de sauvegarde:
http://dev.mysql.com/doc/refman/5.6/en/savepoint.html
Après avoir lu le manuel et ce rapport de bogue, il semble que si des points de sauvegarde sont libérés, ils libéreront des verrous sur la table en cours de travail, ce qui peut éviter les problèmes de verrouillage qui ont été vus sur mysqldump aussi récemment que MySQL 5.5.
J'espère que cela donne un peu plus d'informations sur l'outil mydumper.