QueryRunner correspondent à des requêtes que le moteur exécute.
Le moteur peut être utilisé pour l’exécution asynchrone de requêtes, l’exécution par lots de requêtes générées,
l’acheminement de requêtes vers des clusters distants, les tests de performance, le fuzzing et les tests sur trafic miroir.
Créer une table
query, database, settings.
La colonne query est obligatoire, les autres colonnes étant facultatives.
Paramètres du moteur
Détails
INSERT SELECT).
Le succès de chaque requête peut être vérifié dans la table system.query_log, où les requêtes initiées par
ce moteur sont marquées avec is_internal = 1 sur le serveur initiateur.
Les requêtes en file d’attente sont conservées en mémoire et ne survivent pas à un redémarrage du serveur. Lors de l’arrêt du serveur
(ou d’un DROP/DETACH de la table), les requêtes qui n’ont pas encore démarré sont ignorées. Parmi les
requêtes déjà en cours d’exécution, celles envoyées à un cluster sont annulées, tandis que celles exécutées
localement sont attendues jusqu’à la fin de leur exécution.
Lorsqu’une requête à exécuter est elle-même un INSERT, ses données doivent être intégrées — INSERT ... VALUES (...),
INSERT ... SELECT ..., ou INSERT ... FORMAT ... avec les données dans le texte de la requête. Un INSERT qui
attend ses données d’un flux distinct n’est pas pris en charge.
Mode local et SQL SECURITY
cluster, les requêtes sont exécutées sur le serveur local.
L’utilisateur sous l’identité duquel elles s’exécutent est déterminé par la clause SQL SECURITY :
INVOKER(par défaut) : les requêtes s’exécutent au nom de l’utilisateur qui a effectué l’INSERT.DEFINER: les requêtes s’exécutent au nom de l’utilisateurDEFINERspécifié. Comme les requêtes insérées peuvent être arbitraires, accorderINSERTsur une telle table délègue tous les privilèges de cet utilisateur.NONE: les requêtes s’exécutent avec un accès complet, sans utilisateur. Nécessite le privilègeALLOW_SQL_SECURITY_NONElors de la création de la table.
Mode cluster
cluster est spécifié, les requêtes sont envoyées au cluster indiqué.
Le shard cible est sélectionné par shard : un index fixe indexé à partir de 1 ('1' par défaut), 'random' pour choisir un
shard aléatoire pour chaque requête, ou 'all' pour exécuter chaque requête sur tous les shards du cluster. Une réplique au sein
du shard est choisie selon le paramètre load_balancing du serveur.
La colonne database définit la base de données par défaut de la connexion au serveur distant. Comme la
base de données par défaut n’est définie qu’une seule fois par connexion, chaque valeur distincte de database utilise son propre
pool de connexions, qui est créé lors de la première utilisation puis réutilisé pendant toute la durée de vie de la table.
DEFINER et SQL SECURITY n’ont d’effet qu’en mode local, et les combiner avec le
paramètre cluster constitue une erreur. Sur les serveurs distants, les requêtes sont authentifiées à l’aide des
informations d’identification de la configuration du cluster et s’exécutent comme des requêtes initiales ordinaires : elles sont consignées dans
system.query_log avec is_initial_query = 1 et leur propre query_id (sans lien avec l’INSERT qui
les a produites). Sur le serveur initiateur, les requêtes envoyées sont consignées dans system.query_log
avec is_internal = 1.
Comme le moteur ignore le résultat de la requête, il exécute toujours les requêtes envoyées avec
discard_query_data = 1, de sorte que les données de résultat des requêtes SELECT ne sont pas transférées sur le réseau
(cela remplace toute valeur discard_query_data définie dans la colonne settings).
Attendre la fin des requêtes
Exemple
SELECT récentes à partir du journal des requêtes :