Поскольку версия Apache ShardingSphere 5.0.0-Beta включала DistSQL, это сделало проект все более популярным среди разработчиков и команд эксплуатации за его преимущества, такие как динамические эффекты, отсутствие перезапуска и элегантный синтаксис, близкий к стандартному SQL.
С обновлениями до 5.0.0 и 5.1.0 сообщество ShardingSphere еще раз добавило богатый синтаксис в DistSQL, предоставив больше практических функций.
В этом посте соавторы сообщества поделятся последними функциями DistSQL с точки зрения «управления кластером».
Кластер ShardingSphere
В типичном кластере, состоящем из ShardingSphere-Proxy, есть несколько вычислительных узлов и узлов хранения, как показано на рисунке ниже:
Чтобы упростить понимание, в ShardingSphere мы называем прокси-сервер
compute node, а ресурсы распределенной базы данных, управляемые прокси-сервером (например,ds_0,ds_1), —resourcesилиstorage nodes.
Несколько прокси-серверов или вычислительных узлов подключены к одному и тому же центру регистрации, имеют общую конфигурацию и правила и могут отслеживать онлайн-статус друг друга.
Эти вычислительные узлы также совместно используют базовые узлы хранения, поэтому они могут одновременно выполнять операции чтения и записи на узлах хранения. Пользовательское приложение подключается к любому вычислительному узлу и может выполнять аналогичные операции.
Благодаря этой кластерной архитектуре вы можете быстро масштабировать Proxy по горизонтали, когда вычислительных ресурсов недостаточно, что снижает риск единой точки отказа и повышает доступность системы.
Механизм балансировки нагрузки также можно добавить между приложением и вычислительным узлом.
Управление вычислительным узлом
Управление вычислительным узлом подходит для режима кластера. Для получения дополнительной информации о режимах ShardingSphere см. Подробное руководство по режимам работы Apache ShardingSphere.
Подготовка кластера
В качестве примера возьмем автономную симуляцию трех вычислительных узлов Proxy. Чтобы использовать режим, следуйте приведенной ниже конфигурации:
mode: type: Cluster repository: type: ZooKeeper props: namespace: governance_ds server-lists: localhost:2181 retryIntervalMilliseconds: 500 timeToLiveSeconds: 60 maxRetries: 3 operationTimeoutMilliseconds: 500 overwrite: false
Выполните команду загрузки отдельно:
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3307 sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3308 sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3309
После успешного запуска трех экземпляров Proxy кластер вычислительных узлов готов.
SHOW INSTANCE LIST
Используйте клиент для подключения к любому вычислительному узлу, например 3307:
mysql -h 127.0.0.1 -P 3307 -u root -p
Просмотрите список экземпляров:
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 | +----------------+-----------+------+---------+
Вышеуказанные поля означают:
instance_id: идентификатор экземпляра, который в настоящее время состоит из хоста и порта.Host: адрес хоста.Port: номер порта.Status: статус экземпляраenabledилиdisabled
DISABLE INSTANCE
DISABLE INSTANCE statement используется для перевода указанного вычислительного узла в отключенное состояние.
💡Примечание: оператор не завершает процесс целевого экземпляра, а лишь фактически деактивирует его.
DISABLE INSTANCE поддерживает следующие формы синтаксиса:
DISABLE INSTANCE 10.7.5.35@3308; #or DISABLE INSTANCE IP=10.7.5.35, PORT=3308;
Пример:
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 | +----------------+-----------+------+----------+
Выполнив оператор DISABLE INSTANCE , повторив запрос, вы увидите, что состояние экземпляра порта 3308 было обновлено до disabled , что указывает на то, что вычислительный узел был отключен.
Если к 10.7.5.35@3308 подключен клиент, выполнение любого оператора SQL вызовет исключение:
1000 - Circuit break mode is ON.
💡Примечание. Нельзя отключать текущий вычислительный узел. Если вы отправите10.7.5.35@3309 кому DISABLE INSTANCE 10.7.5.35@3309 , выполучите запрос об исключении.
ENABLE INSTANCE
ENABLE INSTANCE statement используется для перевода указанного вычислительного узла во включенное состояние. ENABLE INSTANCE поддерживает следующие формы синтаксиса:
ENABLE INSTANCE 10.7.5.35@3308; #or ENABLE INSTANCE IP=10.7.5.35, PORT=3308;
Пример:
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 | +----------------+-----------+------+----------+
После выполнения оператора ENABLE INSTANCE вы можете запросить еще раз и увидеть, что состояние экземпляра порта 3308 было восстановлено до enabled.
Как управлять параметрами вычислительного узла
В предыдущей статье Интеграция SCTL в RAL — сделать Apache ShardingSphere идеальным для управления базами данных мы объяснили эволюцию SCTL (язык управления ShardingSphere) в RAL (язык управления ресурсами и правилами) и новый синтаксис SHOW VARIABLE and SET VARIABLE .
Однако в версии 5.0.0-Beta VARIABLE category DistSQL RAL содержит только следующие три утверждения:
SET VARIABLE TRANSACTION_TYPE = xx; （LOCAL, XA, BASE） SHOW VARIABLE TRANSACTION_TYPE; SHOW VARIABLE CACHED_CONNECTIONS;
Прислушиваясь к отзывам сообщества, мы заметили, что запрос и изменение конфигурации реквизита прокси (расположенного в server.yaml)) также является частой операцией. Поэтому мы добавили поддержку конфигурации реквизита в DistSQL RAL, начиная с версии 5.0.0 GA.
SHOW VARIABLE
Во-первых, давайте рассмотрим, как настроить реквизит:
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
Теперь вы можете выполнять интерактивные запросы, используя следующий синтаксис:
SHOW VARIABLE PROXY_PROPERTY_NAME;
Пример:
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) ……
💡Примечание. Для синтаксиса DistSQL ключи параметров разделяются символами подчеркивания.
SHOW ALL VARIABLES
Так как в Proxy есть много параметров, вы также можете запросить значения всех параметров через 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)
SET VARIABLE
Динамическое управление ресурсами и правилами — особое преимущество DistSQL. Теперь вы также можете динамически обновлять параметры реквизита, используя SET VARIABLE statement. Например:
#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; ……
💡Примечание:
- Следующие параметры могут быть изменены оператором
SET VARIABLEs, но новое значение вступает в силу только после перезапуска прокси-сервера:
kernel_executor_sizeproxy_frontend_executor_sizeproxy_backend_driver_type
2. Следующие параметры доступны только для чтения и не могут быть изменены:
cached_connections
3. Другие параметры вступят в силу сразу после изменения.
Как управлять узлами хранения
В ShardingSphere узлы хранения не связаны напрямую с вычислительными узлами. Потому что один узел хранения может одновременно играть разные роли в разных схемах для реализации разной бизнес-логики. Узлы хранения всегда связаны со схемой.
Для DistSQL узлы хранения управляются с помощью операторов RESOURCE related, в том числе:
ADD RESOURCEALTER RESOURCEDROP RESOURCESHOW SCHEMA RESOURCES
Подготовка схемы
Операторы RESOURCE related работают только со схемами, поэтому перед операцией вам необходимо создать и использовать USE command для успешного выбора схемы:
DROP DATABASE IF EXISTS sharding_db; CREATE DATABASE sharding_db; USE sharding_db;
ADD RESOURCE
ADD RESOURCE поддерживает следующие формы синтаксиса:
- Укажите
HOST,PORT,DB
ADD RESOURCE resource_0 ( HOST=127.0.0.1, PORT=3306, DB=db0, USER=root, PASSWORD=root );
- Укажите
URL
ADD RESOURCE resource_1 ( URL="jdbc:mysql://127.0.0.1:3306/db1?serverTimezone=UTC&useSSL=false", USER=root, PASSWORD=root );
Приведенные выше две формы синтаксиса поддерживают параметр расширения PROPERTIES , который используется для указания конфигурации атрибутов пула соединений между прокси-сервером и узлом хранения, например:
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")
);
💡 Примечание. Указание параметров подключения JDBC, таких как useSSL, поддерживается только с формой URL.
ИЗМЕНИТЬ РЕСУРС
ALTER RESOURCE используется для изменения информации о соединении узлов хранения, например, для изменения размера пула соединений, изменения параметров соединения JDBC и т. д.
Синтаксически ALTER RESOURCE идентично 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")
);
💡 Примечание. Поскольку изменение узла хранения может привести к изменению метаданных или исключению данных приложения, ALTER RESOURCE нельзя использовать для изменения целевой базы данных соединения. Можно изменить только следующие значения:
- Имя пользователя
- Пользовательский пароль
PROPERTIESпараметры пула соединений- JDBC-параметры
DROP RESOURCE
DROP RESOURCE используется для удаления узлов хранения из схемы без удаления каких-либо данных в узле хранения. Пример заявления выглядит следующим образом:
DROP RESOURCE resource_0, resource_1;
💡Примечание. Чтобы обеспечить правильность данных, узел хранения, на который ссылается правило, не может быть удален.
t_order — это таблица сегментирования, и ее фактические таблицы распределены в resource_0 и resource_1. Когда resource_0 и resource_1 находятся в t_order правилах сегментирования, их нельзя удалить.
SHOW SCHEMA RESOURCES
SHOW SCHEMA RESOURCES используется для запроса узлов хранения в схемах и поддерживает следующие формы синтаксиса:
#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;
Пример:
Добавьте 4 узла хранения с помощью вышеупомянутой команды ADD RESOURCE , а затем выполните запрос:
На самом деле в результате запроса большое количество столбцов, но здесь мы показываем только часть.
Выше мы познакомили вас со способами динамического управления узлами хранения через DistSQL.
По сравнению с изменением файлов YAML выполнение инструкций DistSQL происходит в режиме реального времени, и нет необходимости перезапускать прокси-сервер или вычислительный узел, что делает онлайн-операции более безопасными.
Изменения, выполняемые через DistSQL, могут быть синхронизированы с другими вычислительными узлами в кластере в режиме реального времени через центр регистрации, при этом клиент, подключенный к любому вычислительному узлу, также может запрашивать изменения узлов хранения в режиме реального времени.
Управление кластером Apache ShardingSphere очень мощное.
Заключение
Если у вас есть какие-либо вопросы или предложения по Apache ShardingSphere, откройте вопрос в списке вопросов GitHub. Если вы заинтересованы в том, чтобы внести свой вклад в проект, вы можете присоединиться к сообществу Apache ShardingSphere.
Проблема GitHub:
Справочник
1. Быстрый запуск ShardingSphere-Proxy:https://shardingsphere.apache.org/document/5.1.0/en/quick-start/shardingsphere-proxy-quick-start/
2.DistSQL RDL: https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/distsql/syntax/rdl/resource-definition/
3.DistSQL RQL: https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/distsql/syntax/rql/resource-query/
4.DistSQL RAL:https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/distsql/syntax/ral/
Ссылки на проект Apache ShardingSphere:
Авторы
Лунтао Цзян
Инженер-разработчик промежуточного программного обеспечения SphereEx и коммиттер Apache ShardingSphere
Цзян работает над DistSQL и исследованиями и разработками в области безопасности.
Чэнсян Лань
Инженер-разработчик промежуточного программного обеспечения SphereEx и коммиттер Apache ShardingSphere
Лан участвует в исследованиях и разработках DistSQL.
Присоединяйтесь к FAUN: Сайт💻|Подкаст🎙️|Twitter🐦|Facebook👥 |Instagram📷|Группа Facebook🗣️|Группа Linkedin💬| Slack 📱|Cloud Native Новости📰|Дополнительно.
Если этот пост был полезен, пожалуйста, несколько раз нажмите кнопку аплодисментов 👏 ниже, чтобы выразить свою поддержку автору 👇
