Recherche de site Web

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 port
  • hôte : adresse de l'hôte
  • port : numéro de port
  • statut : 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.

Articles connexes: