Votre guide sur la capacité de gouvernance de cluster de DistSQL
Une mise à jour des fonctionnalités d'Apache ShardingSphere améliore la gestion dynamique des nœuds de stockage.
La version Apache ShardingSphere 5.0.0-Beta avec DistSQL a rendu le projet encore plus apprécié des développeurs et des équipes opérationnelles pour ses avantages, tels que les effets dynamiques, l'absence de redémarrage et une syntaxe élégante proche du SQL standard. Avec les mises à niveau vers 5.0.0 et 5.1.0, la communauté ShardingSphere a une fois de plus ajouté une syntaxe abondante à DistSQL, apportant des fonctionnalités plus pratiques.
Dans cet article, les co-auteurs de la communauté partageront les dernières fonctions de DistSQL du point de vue de la gouvernance des clusters.
Clusters ShardingSphere
Dans un cluster typique composé de ShardingSphere-Proxy, il existe plusieurs nœuds de calcul et nœuds de stockage, comme le montre la figure ci-dessous.
(Jiang Longtao et Lan Chengxiang, CC BY-SA 4.0)
Pour faciliter la compréhension, dans ShardingSphere, nous appelons proxy un nœud de calcul et les ressources de base de données distribuées gérées par proxy (telles que ds_0 ou ds_1) sont appelées ressources ou <nœuds de stockage.
Plusieurs nœuds proxy ou de calcul sont connectés au même centre d'enregistrement. Ils partagent la configuration et les règles, et peuvent détecter le statut en ligne de chacun. Ces nœuds de calcul partagent également les nœuds de stockage sous-jacents, afin qu'ils puissent effectuer simultanément des opérations de lecture et d'écriture sur les nœuds de stockage. L'application utilisateur est connectée à n'importe quel nœud de calcul et peut effectuer des opérations équivalentes.
Grâce à cette architecture de cluster, vous pouvez rapidement faire évoluer le proxy horizontalement lorsque les ressources de calcul sont insuffisantes, réduisant ainsi le risque d'un point de défaillance unique et améliorant la disponibilité du système. Le mécanisme d'équilibrage de charge peut également être ajouté entre l'application et le nœud de calcul.
Gouvernance des nœuds de calcul
La gouvernance des nœuds de calcul est adaptée au mode cluster. Pour plus d'informations sur les modes ShardingSphere, veuillez consulter Votre guide détaillé des modes de fonctionnement d'Apache ShardingSphere.
Préparation des grappes
Prenons comme exemple une simulation autonome de trois nœuds de calcul proxy. Pour utiliser le mode, suivez la configuration ci-dessous :
mode:
type: Cluster
repository:
type: ZooKeeper
props:
namespace: governance_ds
server-lists: localhost:2181
retryIntervalMilliseconds: 500
timeToLiveSeconds: 60
maxRetries: 3
operationTimeoutMilliseconds: 500
overwrite: false
Exécutez la commande bootup
séparément :
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3307
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3308
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3309
Une fois les trois instances proxy démarrées avec succès, le cluster de nœuds de calcul est prêt.
AFFICHER LA LISTE DES INSTANCES
Utilisez le client pour vous connecter à n'importe quel nœud de calcul, tel que 3307 :
mysql -h 127.0.0.1 -P 3307 -u root -p
Affichez la liste des instances en utilisant SHOW INSTANCE LIST
:
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+---------+
| instance_id | host | port | status |
+----------------+-----------+------+---------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | enabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled |
+----------------+-----------+------+---------+
Les champs ci-dessus signifient :
instance_id
: l'identifiant de l'instance, qui est actuellement composé de l'hôte et du porthôte
: adresse de l'hôteport
: numéro de portstatut
: l'état de l'instance, activé ou désactivé
DÉSACTIVER L'INSTANCE
Utilisez une instruction DISABLE INSTANCE
pour définir le nœud de calcul spécifié sur un état désactivé. L'instruction ne met pas fin au processus de l'instance cible mais la désactive simplement virtuellement.
DISABLE INSTANCE
prend en charge les formes de syntaxe suivantes :
DISABLE INSTANCE 10.7.5.35@3308;
#or
DISABLE INSTANCE IP=10.7.5.35, PORT=3308;
Par exemple:
mysql> DISABLE INSTANCE 10.7.5.35@3308;
Query OK, 0 rows affected (0.02 sec)
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+
| instance_id | host | port | status |
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | disabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled |
+----------------+-----------+------+----------+
Après avoir exécuté l'instruction DISABLE INSTANCE
en effectuant une nouvelle requête, vous pouvez voir que l'état de l'instance du port 3308 a été mis à jour sur disabled
, indiquant que le nœud de calcul a été désactivé.
S'il y a un client connecté à 10.7.5.35@3308
, l'exécution d'une instruction SQL provoquera une exception :
1000 - Circuit break mode is ON.
Vous n'êtes pas autorisé à désactiver le nœud de calcul actuel. Si vous envoyez 10.7.5.35@3309
à DISABLE INSTANCE 10.7.5.35@3309
, vous recevrez une invite d'exception.
ACTIVER L'INSTANCE
Utilisez une instruction ENABLE INSTANCE
pour définir le nœud de calcul spécifié sur un état activé. ENABLE INSTANCE
prend en charge les formes de syntaxe suivantes :
ENABLE INSTANCE 10.7.5.35@3308;
#or
ENABLE INSTANCE IP=10.7.5.35, PORT=3308;
Par exemple:
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+
| instance_id | host | port | status |
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | disabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled |
+----------------+-----------+------+----------+
mysql> ENABLE INSTANCE 10.7.5.35@3308;
Query OK, 0 rows affected (0.01 sec)
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+
| instance_id | host | port | status |
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | enabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled |
+----------------+-----------+------+----------+
Après avoir exécuté l'instruction ENABLE INSTANCE
, vous pouvez interroger à nouveau et voir que l'état de l'instance du port 3308 a été restauré sur enabled
.
Comment gérer les paramètres des nœuds de calcul
Dans notre article Intégrer SCTL dans le RAL de DISTSQL : rendre Apache ShardingSphere parfait pour la gestion de bases de données, nous avons expliqué l'évolution du langage de contrôle ShardingSphere (SCTL) vers le langage d'administration de ressources et de règles (RAL) et le nouveau SHOW VARIABLE
et Syntaxe SET VARIABLE
.
Cependant, dans la version 5.0.0-Beta, la catégorie VARIABLE
de DistSQL RAL ne contenait que les trois instructions suivantes :
SET VARIABLE TRANSACTION_TYPE = xx; (LOCAL, XA, BASE)
SHOW VARIABLE TRANSACTION_TYPE;
SHOW VARIABLE CACHED_CONNECTIONS;
En écoutant les retours de la communauté, nous avons remarqué que l'interrogation et la modification de la configuration des props du proxy (située dans server.yaml
) est également une opération fréquente. Par conséquent, nous avons ajouté la prise en charge de la configuration des accessoires dans DistSQL RAL depuis la version 5.0.0 GA.
AFFICHER LA VARIABLE
Tout d'abord, nous verrons comment configurer les accessoires :
props:
max-connections-size-per-query: 1
kernel-executor-size: 16 # Infinite by default.
proxy-frontend-flush-threshold: 128 # The default value is 128.
proxy-opentracing-enabled: false
proxy-hint-enabled: false
sql-show: false
check-table-metadata-enabled: false
show-process-list-enabled: false
# Proxy backend query fetch size. A larger value may increase the memory usage of ShardingSphere Proxy.
# The default value is -1, which means set the minimum value for different JDBC drivers.
proxy-backend-query-fetch-size: -1
check-duplicate-table-enabled: false
proxy-frontend-executor-size: 0 # Proxy frontend executor size. The default value is 0, which means let Netty decide.
# Available options of proxy backend executor suitable: OLAP(default), OLTP. The OLTP option may reduce time cost of writing packets to client, but it may increase the latency of SQL execution
# and block other clients if client connections are more than `proxy-frontend-executor-size`, especially executing slow SQL.
proxy-backend-executor-suitable: OLAP
proxy-frontend-max-connections: 0 # Less than or equal to 0 means no limitation.
sql-federation-enabled: false
# Available proxy backend driver type: JDBC (default), ExperimentalVertx
proxy-backend-driver-type: JDBC
Vous pouvez désormais effectuer des requêtes interactives en utilisant la syntaxe suivante :
SHOW VARIABLE PROXY_PROPERTY_NAME;
Par exemple:
mysql> SHOW VARIABLE MAX_CONNECTIONS_SIZE_PER_QUERY;
+--------------------------------+
| max_connections_size_per_query |
+--------------------------------+
| 1 |
+--------------------------------+
1 row in set (0.00 sec)
mysql> SHOW VARIABLE SQL_SHOW;
+----------+
| sql_show |
+----------+
| false |
+----------+
1 row in set (0.00 sec)
……
Remarque : Pour la syntaxe DistSQL, les clés de paramètre sont séparées par des traits de soulignement.
AFFICHER TOUTES LES VARIABLES
Comme il existe de nombreux paramètres dans le proxy, vous pouvez également interroger toutes les valeurs des paramètres via AFFICHER TOUTES LES VARIABLES
:
mysql> SHOW ALL VARIABLES;
+---------------------------------------+----------------+
| variable_name | variable_value |
+---------------------------------------+----------------+
| sql_show | false |
| sql_simple | false |
| kernel_executor_size | 0 |
| max_connections_size_per_query | 1 |
| check_table_metadata_enabled | false |
| proxy_frontend_database_protocol_type | |
| proxy_frontend_flush_threshold | 128 |
| proxy_opentracing_enabled | false |
| proxy_hint_enabled | false |
| show_process_list_enabled | false |
| lock_wait_timeout_milliseconds | 50000 |
| proxy_backend_query_fetch_size | -1 |
| check_duplicate_table_enabled | false |
| proxy_frontend_executor_size | 0 |
| proxy_backend_executor_suitable | OLAP |
| proxy_frontend_max_connections | 0 |
| sql_federation_enabled | false |
| proxy_backend_driver_type | JDBC |
| agent_plugins_enabled | false |
| cached_connections | 0 |
| transaction_type | LOCAL |
+---------------------------------------+----------------+
21 rows in set (0.01 sec)
RÉGLER LA VARIABLE
La gestion dynamique des ressources et des règles est un avantage particulier de DistSQL. Vous pouvez désormais également mettre à jour dynamiquement les paramètres des accessoires en utilisant l'instruction SET VARIABLE
. Par exemple:
#Enable SQL log output
SET VARIABLE SQL_SHOW = true;
#Turn on hint function
SET VARIABLE PROXY_HINT_ENABLED = true;
#Open federal query
SET VARIABLE SQL_FEDERATION_ENABLED = true;
……
L'instruction SET VARIABLE
peut modifier les paramètres suivants, mais la nouvelle valeur ne prend effet qu'après le redémarrage du proxy :
kernel_executor_size
proxy_frontend_executor_size
proxy_backend_driver_type
Les paramètres suivants sont en lecture seule et ne peuvent pas être modifiés :
cached_connections
Les autres paramètres prendront effet immédiatement après modification.
Comment gérer les nœuds de stockage
Dans ShardingSphere, les nœuds de stockage ne sont pas directement liés aux nœuds de calcul. Un nœud de stockage peut jouer simultanément différents rôles dans différents schémas, afin de mettre en œuvre différentes logiques métier. Les nœuds de stockage sont toujours associés à un schéma.
Pour DistSQL, les nœuds de stockage sont gérés via des instructions liées à RESOURCE
, notamment :
ADD RESOURCE
ALTER RESOURCE
DROP RESOURCE
SHOW SCHEMA RESOURCES
Préparation du schéma
Les instructions liées à RESOURCE
ne fonctionnent que sur les schémas, donc avant d'opérer, vous devez créer et utiliser la commande USE
pour sélectionner avec succès un schéma :
DROP DATABASE IF EXISTS sharding_db;
CREATE DATABASE sharding_db;
USE sharding_db;
AJOUTER UNE RESSOURCE
ADD RESOURCE
prend en charge les formes de syntaxe suivantes :
- Spécifiez
HOST
,PORT
,DB
ADD RESOURCE resource_0 (
HOST=127.0.0.1,
PORT=3306,
DB=db0,
USER=root,
PASSWORD=root
);
- Spécifier l'URL
ADD RESOURCE resource_1 (
URL="jdbc:mysql://127.0.0.1:3306/db1?serverTimezone=UTC&useSSL=false",
USER=root,
PASSWORD=root
);
Les deux formes de syntaxe ci-dessus prennent en charge le paramètre d'extension PROPERTIES
, qui est utilisé pour spécifier la configuration des attributs du pool de connexions entre le proxy et le nœud de stockage.
Par exemple:
ADD RESOURCE resource_2 (
HOST=127.0.0.1,
PORT=3306,
DB=db2,
USER=root,
PASSWORD=root,
PROPERTIES("maximumPoolSize"=10)
),resource_3 (
URL="jdbc:mysql://127.0.0.1:3306/db3?serverTimezone=UTC&useSSL=false",
USER=root,
PASSWORD=root,
PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
);
La spécification des paramètres de connexion Java Database Connectivity (JDBC), tels que useSSL
, est prise en charge uniquement avec le formulaire URL.
MODIFIER LA RESSOURCE
Utilisez ALTER RESOURCE
pour modifier les informations de connexion des nœuds de stockage, par exemple en changeant la taille d'un pool de connexions ou en modifiant les paramètres de connexion JDBC.
Syntaxiquement, ALTER RESOURCE
est identique à ADD RESOURCE
.
ALTER RESOURCE resource_2 (
HOST=127.0.0.1,
PORT=3306,
DB=db2,
USER=root,
PROPERTIES("maximumPoolSize"=50)
),resource_3 (
URL="jdbc:mysql://127.0.0.1:3306/db3?serverTimezone=GMT&useSSL=false",
USER=root,
PASSWORD=root,
PROPERTIES("maximumPoolSize"=50,"idleTimeout"="30000")
);
Étant donné que la modification du nœud de stockage peut entraîner des modifications de métadonnées ou des exceptions de données d'application, ALTER RESOURCE
ne peut pas être utilisé pour modifier la base de données cible de la connexion. Seules les valeurs suivantes peuvent être modifiées :
- Nom d'utilisateur
- Mot de passe de l'utilisateur
- Paramètres du pool de connexions
PROPERTIES
- Paramètres JDBC
LAISSER LA RESSOURCE
Utilisez DROP RESOURCE
pour supprimer des nœuds de stockage d'un schéma sans supprimer aucune donnée dans le nœud de stockage. L'exemple d'instruction est le suivant :
DROP RESOURCE resource_0, resource_1;
Pour garantir l'exactitude des données, le nœud de stockage référencé par la règle ne peut pas être supprimé.
t_order
est une table de partitionnement, et ses tables réelles sont distribuées dans resource_0
et resource_1
. Lorsque resource_0
et resource_1
sont référencés par les règles de partitionnement t_order
, ils ne peuvent pas être supprimés.
AFFICHER LES RESSOURCES DU SCHÉMA
SHOW SCHEMA RESOURCES
est utilisé pour interroger les nœuds de stockage dans les schémas et prend en charge les formes de syntaxe suivantes :
#Query the storage node in the current schema
SHOW SCHEMA RESOURCES;
#Query the storage node in the specified schema
SHOW SCHEMA RESOURCES FROM sharding_db;
Par exemple, ajoutez quatre nœuds de stockage via la commande ADD RESOURCE
, puis exécutez une requête :
(Jiang Longtao et Lan Chengxiang, CC BY-SA 4.0)
Il existe de nombreuses colonnes dans le résultat de la requête, mais ici nous n'en montrons qu'une partie.
Conclusion
Dans cet article, nous vous avons présenté les façons dont vous pouvez gérer dynamiquement les nœuds de stockage via DistSQL.
Contrairement à la modification des fichiers YAML, l'exécution des instructions DistSQL s'effectue en temps réel et il n'est pas nécessaire de redémarrer le proxy ou le nœud de calcul, ce qui rend les opérations en ligne plus sûres. Les modifications exécutées via DistSQL peuvent être synchronisées avec d'autres nœuds de calcul du cluster en temps réel via le centre d'enregistrement. Le client connecté à n'importe quel nœud de calcul peut également interroger les modifications des nœuds de stockage en temps réel.
Si vous avez des questions ou des suggestions sur Apache ShardingSphere, veuillez ouvrir un problème sur la liste des problèmes GitHub. Si vous souhaitez contribuer au projet, vous êtes les bienvenus pour rejoindre la communauté Apache ShardingSphere.
Liens du projet Apache ShardingSphere :
- ShardingSphere Github
- Twitter de ShardingSphere
- ShardingSphere Slack
- Guide du contributeur
Cet article a été initialement publié sur FAUN et est republié avec autorisation.