Votre guide sur la capacité de gouvernance de cluster de DistSQL

par ·


  • Français


    • 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.

    Grappes ShardingSphere

    Dans un cluster typique composé de ShardingSphere-Proxy, il existe plusieurs nœuds de calcul et nœuds de stockage, comme illustré dans la figure ci-dessous.

    Image par :

    (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 des ressources de base de données distribuées gérées par proxy (telles que ds_0 ou ds_1) en tant que Ressources ou nœuds de stockage.

    Plusieurs nœuds proxy ou de calcul sont connectés au même centre de registre. Ils partagent la configuration et les règles, et ils peuvent détecter le statut en ligne de l’autre. Ces nœuds de calcul partagent également les nœuds de stockage sous-jacents, de sorte qu’ils peuvent effectuer des opérations de lecture et d’écriture sur les nœuds de stockage en même temps. 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 convient 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 l’exemple d’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 le bootup commande 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 de proxy démarrées avec succès, le cluster de nœuds de calcul est prêt.

    AFFICHER LA LISTE D’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

    Afficher la liste des instances 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
    • host: Adresse de l’hôte
    • port: Numéro de port
    • status: Le statut de l’instance, activé ou désactivé

    DÉSACTIVER L’INSTANCE

    Utiliser un 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 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é le DISABLE INSTANCE en interrogeant à nouveau, vous pouvez voir que l’état de l’instance du port 3308 a été mis à jour pour disabledindiquant que le nœud de calcul a été désactivé.

    Si un client est connecté à 10.7.5.35@3308l’exécution de toute instruction SQL déclenchera une exception :

    1000 - Circuit break mode IS ON.

    Vous n’êtes pas autorisé à désactiver le nœud de calcul actuel. Si tu envoies 10.7.5.35@3309 à DISABLE INSTANCE 10.7.5.35@3309vous recevrez une invite d’exception.

    ACTIVER L’INSTANCE

    Utilisez un 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é le ENABLE INSTANCE vous pouvez interroger à nouveau et voir que l’état de l’instance du port 3308 a été restauré à enabled.

    Comment gérer les paramètres du nœud de calcul

    Dans notre article Intégration de SCTL dans le RAL de DISTSQL : rendre Apache ShardingSphere parfait pour la gestion de bases de donnéesnous avons expliqué l’évolution du langage de contrôle ShardingSphere (SCTL) vers le langage d’administration des ressources et des règles (RAL) et le nouveau SHOW VARIABLE et SET VARIABLE syntaxe.

    Cependant, dans la version 5.0.0-bêta, le VARIABLE catégorie 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 props du proxy (situé 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 LES VARIABLES

    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 maintenant 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

    Étant donné qu’il existe de nombreux paramètres dans le proxy, vous pouvez également interroger toutes les valeurs de paramètre via SHOW ALL 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. Maintenant, vous pouvez également mettre à jour dynamiquement les paramètres des accessoires en utilisant le SET VARIABLE déclaration. 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;
    ……

    La 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 :

    Les autres paramètres prendront effet immédiatement après la 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 différents rôles dans différents schémas en même temps, afin de mettre en œuvre une logique métier différente. Les nœuds de stockage sont toujours associés à un schéma.

    Pour DistSQL, les nœuds de stockage sont gérés via RESOURCE– déclarations connexes, y compris :

    • ADD RESOURCE
    • ALTER RESOURCE
    • DROP RESOURCE
    • SHOW SCHEMA RESOURCES

    Préparation du schéma

    RESOURCE-les instructions liées ne fonctionnent que sur les schémas, donc avant d’opérer, vous devez créer et utiliser le USE commande 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 :

    ADD RESOURCE resource_0 (
    HOST=127.0.0.1,
    PORT=3306,
    DB=db0,
    USER=root,
    PASSWORD=root
    );
    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 PROPERTIESqui est utilisé pour spécifier la configuration d’attribut du pool de connexion 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")
    );

    Spécification des paramètres de connexion Java Database Connectivity (JDBC), tels que useSSLn’est pris en charge qu’avec le formulaire d’URL.

    MODIFIER LA RESSOURCE

    Utilisation ALTER RESOURCE pour modifier les informations de connexion des nœuds de stockage, telles que la modification de la taille d’un pool de connexions ou la modification des 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
    • PROPERTIES paramètres du pool de connexions
    • Paramètres JDBC

    DÉPOSER UNE RESSOURCE

    Utilisation 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_0et resource_1. Lorsque resource_0 et resource_1 sont référencés par t_order règles de partitionnement, elles ne peuvent pas être supprimées.

    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 le ADD RESOURCE commande, puis exécutez une requête :

    Image par :

    (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 se produit 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 de registre. 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 concernant Apache ShardingSphere, veuillez ouvrir un ticket sur le Liste des problèmes GitHub. Si vous êtes intéressé à contribuer au projet, vous êtes le bienvenu pour rejoindre la communauté Apache ShardingSphere.

    Liens du projet Apache ShardingSphere :

    Cet article est initialement paru sur FAUNE et est republié avec autorisation.

    Source

    Étiquettes :

    Houssen Moshinaly

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

    Copy code