DistSQL (расшифровывается как Distributed SQL) — это специализированный операционный язык, эксклюзивный для Apache ShardingSphere. Этот язык предоставляет пользователям упрощенную и мощную динамическую систему управления, которая позволяет им работать с ShardingSphere как с традиционной базой данных.
Одним из ключевых преимуществ использования DistSQL является возможность определять ресурсы и правила в режиме онлайн без необходимости изменять файлы YAML и перезапускать систему. Это упрощает процесс управления и снижает вероятность ошибок.
По мере расширения возможностей DistSQL и более близкого знакомства пользователей с ним возник ряд вопросов по поводу его использования. В этом посте мы рассмотрим некоторые из этих вопросов и обсудим, почему они имеют отношение к сегодняшней теме.
Вот некоторые из наиболее распространенных вопросов о DistSQL:
- Где хранятся правила, определенные DistSQL?
- Как перенести определенную конфигурацию DistSQL в новую среду при наличии нескольких тестовых сред?
- Как написать синтаксис DistSQL?
Где хранятся правила, определенные DistSQL?
При использовании DistSQL часто возникает вопрос, где хранятся правила, определенные языком. Ответ заключается в том, что эти правила хранятся в Центре управления, который действует как централизованное хранилище данных конфигурации.
В кластерном режиме пользователи могут использовать ZooKeeper или etcd в качестве Центра управления, а в автономном режиме пользователи могут указать свой предпочтительный метод сохранения. По умолчанию DistSQL использует непостоянный режим H2. Однако пользователям рекомендуется использовать режим кластера, чтобы в полной мере использовать возможности DistSQL.
Сохраняя правила в централизованном месте, DistSQL упрощает управление и изменение конфигураций. Это улучшает общее взаимодействие с пользователем и оптимизирует процесс управления, позволяя пользователям сосредоточиться на более важных задачах.
Как перенести определенную конфигурацию DistSQL в новую среду при наличии нескольких тестовых сред?
При использовании DistSQL одна потенциальная проблема, с которой могут столкнуться пользователи, — перенос резервных копий данных из Центра управления в новую среду. Этот процесс может быть сложным и занимать много времени, особенно если данные хранятся на нескольких узлах.
Для решения этой проблемы DistSQL предоставляет синтаксис EXPORT, который позволяет пользователям экспортировать логические конфигурации базы данных в формат YAML. Это упрощает перенос данных в новую среду и упрощает процесс резервного копирования.
Независимо от того, используете ли вы автономный или кластерный режим, синтаксис EXPORT предоставляет мощный инструмент для управления и переноса данных. Упрощая процесс резервного копирования, DistSQL улучшает взаимодействие с пользователем и повышает общую эффективность.
У нас есть потребность в регулярном резервном копировании данных. Как создать резервную копию конфигурации логической базы данных? Использование определений DistSQL.
Как мы обсуждали в предыдущем вопросе, использование синтаксиса EXPORT в DistSQL позволяет пользователям экспортировать логические конфигурации базы данных в формат YAML. Эта функция служит полезным инструментом резервного копирования, поскольку позволяет пользователям легко сохранять и переносить данные в новую среду.
Экспортируя данные в виде файла YAML, пользователи могут обеспечить безопасное резервное копирование своих данных и их доступность в случае любых непредвиденных проблем или сбоев системы. Это обеспечивает душевное спокойствие и помогает гарантировать, что важные данные никогда не будут потеряны.
В целом синтаксис EXPORT в DistSQL является ценным инструментом, расширяющим возможности управления языком. Независимо от того, используете ли вы его для переноса данных в новую среду или просто для резервного копирования данных, синтаксис EXPORT упрощает процесс и упрощает уверенное управление вашими данными.
Влияет ли перезапуск формата YAML при помещении его в новый экземпляр ShardingSphere?
После экспорта файла YAML с использованием синтаксиса EXPORT в DistSQL у пользователей есть несколько вариантов загрузки данных обратно в систему. Один из распространенных подходов — поместить файл YAML непосредственно в каталог conf прокси-сервера. Однако, если прокси-сервер уже запущен, может потребоваться перезагрузка, чтобы изменения вступили в силу.
Более удобной альтернативой является использование оператора IMPORT для динамической загрузки данных в систему. Такой подход позволяет прокси-серверу записывать данные в Центр управления, не требуя перезагрузки, что может сэкономить время и сократить количество сбоев в работе системы.
Используя оператор IMPORT, пользователи могут в полной мере воспользоваться возможностями динамического управления DistSQL. Это позволяет им вносить изменения в систему «на лету», без необходимости ручного вмешательства или перезапуска системы. В целом, возможность динамической загрузки данных улучшает взаимодействие с пользователем и упрощает управление и поддержку стабильной и надежной системы.
Я настроил шардинг и правила разделения чтения/записи. Могу ли я показывать только [2][3] отдельно при запросе? Есть ли способ показать их вместе?
Оператор EXPORT в DistSQL не только служит средством резервного копирования, но также может использоваться для быстрого просмотра логических конфигураций базы данных. По умолчанию, если параметр TO FILE не указан, результаты EXPORT выводятся в наборе результатов запроса.
Это предоставляет пользователям удобный способ быстрого доступа и просмотра конфигураций своих баз данных без необходимости перемещаться по различным файлам или каталогам. Используя оператор EXPORT, пользователи могут лучше понять общее состояние своей системы и принимать более обоснованные решения о том, как управлять ею и поддерживать ее.
DistSQL выглядит хорошо, но я настраивал его в YAML и не знаю, как писать синтаксис DistSQL. Кто-нибудь может научить меня?
В дополнение к синтаксисам EXPORT и IMPORT, которые мы обсуждали ранее, сообщество также разработало синтаксис CONVERT, который можно использовать для преобразования инструкций YAML в DistSQL.
Синтаксис CONVERT предоставляет пользователям удобный способ преобразования своих конфигураций YAML в операторы DistSQL, которые можно изучить или скопировать напрямую. Это упрощает пользователям управление конфигурациями баз данных и их обслуживание, а также гарантирует, что они могут быстро и легко вносить изменения в свою систему по мере необходимости.
В целом, комбинация синтаксисов EXPORT, IMPORT и CONVERT в DistSQL предоставляет пользователям надежный набор инструментов для управления и обслуживания логических конфигураций базы данных. Независимо от того, выполняете ли вы резервное копирование данных, загружаете их динамически или конвертируете в операторы DistSQL, эти синтаксис может помочь вам оптимизировать рабочий процесс и упростить уверенное управление вашей системой.
Грамматическое исключение
ЭКСПОРТ КОНФИГУРАЦИИ БАЗЫ ДАННЫХ
Одним из ключевых синтаксисов DistSQL является EXPORT DATABASE CONFIGURATION, который используется для экспорта конфигурации логической базы данных, включая источники данных и правила, в формат YAML. Используя этот синтаксис, пользователи могут быстро и легко создавать резервные копии своих системных конфигураций и обеспечивать надежную и актуальную запись своих системных настроек.
При выполнении EXPORT DATABASE CONFIGURATION пользователи могут указать расположение и формат экспортируемого файла с помощью параметра TO FILE. Если этот параметр не указан, результаты будут выводиться в наборе результатов запроса.
EXPORT DATABASE CONFIGURATION (FROM databaseName)? (TO FILE filePath)?
Описания следующие:
FROM databaseName is used to specify the logical database to be exported. When FROM databaseName is not specified, the logical database currently in use is exported. When the TO FILE filePath parameter is specified, the export information will be exported to the target file. If the file does not exist, it will be created automatically; if it already exists, it will be overwritten. filePath is of type STRING.
ИМПОРТ КОНФИГУРАЦИИ БАЗЫ ДАННЫХ
Еще один важный синтаксис DistSQL — IMPORT DATABASE CONFIGURATION, который используется для импорта конфигураций, включая источники данных и правила, из файла YAML. Этот синтаксис предоставляет пользователям удобный и эффективный способ загрузки своих конфигураций в DistSQL без необходимости вручную определять каждый компонент.
При выполнении IMPORT DATABASE CONFIGURATION пользователи могут указать расположение файла YAML с помощью параметра FROM FILE. Используя этот синтаксис, пользователи могут быстро и легко загружать свои конфигурации в DistSQL и следить за тем, чтобы их система была обновлена и точно отражала их настройки.
Одним из ключевых преимуществ синтаксиса IMPORT DATABASE CONFIGURATION является то, что он может выполняться динамически, без необходимости перезапуска системы. Это упрощает управление и обслуживание системы во время ее работы без прерывания или прерывания нормальной работы.
Импорт в текущую базу данных логики:
IMPORT DATABASE CONFIGURATION FROM FILE filePath
Описания следующие:
The file to be imported must conform to the Proxy's YAML configuration format. The import target must be an empty logical database, i.e. the logical database currently in use has no storage nodes and no rule configuration. The file must contain databaseName and be consistent with the name of the logical repository being operated on. The file must contain the dataSources storage resource configuration. filePath is of type STRING.
ПРЕОБРАЗОВАТЬ КОНФИГУРАЦИЮ YAML
Используется для преобразования конфигураций YAML в соответствующие операторы DistSQL.
CONVERT YAML CONFIGURATION FROM FILE filePath
Описания следующие:
- Преобразуемый файл должен соответствовать формату конфигурации Proxy YAML.
- filePath имеет тип STRING.
Практическая демонстрация
Чтобы продемонстрировать использование синтаксиса IMPORT и EXPORT DATABASE CONFIGURATION в DistSQL, мы будем использовать сценарий MySQL с ShardingSphere-Proxy, развернутым в кластерном режиме. Прежде чем мы начнем, необходимо выполнить несколько ключевых шагов для подготовки среды:
- Создайте две базы данных, demo_ds_0 и demo_ds_1, в MySQL. Эти базы данных будут использоваться для хранения наших данных и тестирования наших конфигураций.
- Запустите службу ZooKeeper. Это предоставит нам необходимую инфраструктуру для управления конфигурациями нашей системы.
- Настройте информацию о режиме в файле server.yaml ShardingSphere-Proxy и запустите службу прокси. Это позволит нам подключаться к нашим базам данных MySQL и управлять нашими конфигурациями с помощью DistSQL [4].
Выполнив эти шаги, мы теперь готовы начать работу с синтаксисом IMPORT и EXPORT DATABASE CONFIGURATION.
База данных логики конфигурации
- Создать логическую базу данных
CREATE DATABASE sharding_db; USE sharding_db;
2. Зарегистрируйте узлы хранения
REGISTER STORAGE UNIT ds_0 (
URL="jdbc:mysql://127.0.0.1:3306/demo_ds_0?serverTimezone=UTC&useSSL=false",
USER="root",
PASSWORD="123456",
PROPERTIES("maximumPoolSize"=10)
),ds_1 (
URL="jdbc:mysql://127.0.0.1:3306/demo_ds_1?serverTimezone=UTC&useSSL=false",
USER="root",
PASSWORD="123456",
PROPERTIES("maximumPoolSize"=10)
);
3. Создание правил шардинга
CREATE SHARDING TABLE RULE t_order (
STORAGE_UNITS(ds_0,ds_1),
SHARDING_COLUMN=order_id,TYPE(NAME=MOD,PROPERTIES("sharding-count"=4)),
KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME="snowflake"))
);
Процесс операции выглядит следующим образом:
Делая это, мы динамически создаем логическую базу данных sharding_db, в которой хранится информация об узле и правила сегментирования в Центре управления ZooKeeper.
ЭКСПОРТ КОНФИГУРАЦИИ БАЗЫ ДАННЫХ
Только просмотр конфигураций
EXPORT DATABASE CONFIGURATION; # or EXPORT DATABASE CONFIGURATION FROM sharding_db;
Пример выполнения
mysql> EXPORT DATABASE CONFIGURATION;
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| result |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| databaseName: sharding_db
dataSources:
ds_1:
password: 123456
url: jdbc:mysql://127.0.0.1:3306/demo_ds_1?serverTimezone=UTC&useSSL=false
username: root
minPoolSize: 1
connectionTimeoutMilliseconds: 30000
maxLifetimeMilliseconds: 2100000
readOnly: false
idleTimeoutMilliseconds: 60000
maxPoolSize: 10
ds_0:
password: 123456
url: jdbc:mysql://127.0.0.1:3306/demo_ds_0?serverTimezone=UTC&useSSL=false
username: root
minPoolSize: 1
connectionTimeoutMilliseconds: 30000
maxLifetimeMilliseconds: 2100000
readOnly: false
idleTimeoutMilliseconds: 60000
maxPoolSize: 10
rules:
- !SHARDING
autoTables:
t_order:
actualDataSources: ds_0,ds_1
keyGenerateStrategy:
column: order_id
keyGeneratorName: t_order_snowflake
logicTable: t_order
shardingStrategy:
standard:
shardingAlgorithmName: t_order_mod
shardingColumn: order_id
keyGenerators:
t_order_snowflake:
type: snowflake
shardingAlgorithms:
t_order_mod:
props:
sharding-count: '4'
type: mod
|
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)
После выполнения EXPORT DATABASE CONFIGURATION логическая конфигурация базы данных представляется в классическом формате YAML.
Экспорт в файл YAML
EXPORT DATABASE CONFIGURATION TO FILE '/Users/xx/sharding_db.yaml'; # or EXPORT DATABASE CONFIGURATION FROM sharding_db TO FILE '/Users/xx/sharding_db.yaml';
Пример выполнения
mysql> EXPORT DATABASE CONFIGURATION TO FILE '/Users/xxx/sharding_db.yaml'; +------------------------------------------------------------------+ | result | +------------------------------------------------------------------+ | Successfully exported to：'/Users/xxx/sharding_db.yaml' | +------------------------------------------------------------------+ 1 row in set (0.01 sec)
После добавления параметра TO FILE результаты EXPORT DATABASE CONFIGURATION выводятся в указанный файл. На следующей диаграмме показано содержимое файла sharding_db.yaml.
ИМПОРТ КОНФИГУРАЦИИ БАЗЫ ДАННЫХ
После успешного экспорта конфигураций нашей базы данных с использованием синтаксиса EXPORT DATABASE CONFIGURATION мы можем использовать полученный файл YAML (в данном случае sharding_db.yaml) для выполнения операции импорта в любом ShardingSphere-Proxy.
Чтобы продемонстрировать, как это работает, давайте сначала удалим метаданные sharding_db из нашей текущей конфигурации. Затем мы можем использовать оператор IMPORT, чтобы импортировать конфигурацию из нашего файла YAML и обновить наши метаданные новой информацией.
Таким образом, используя оператор IMPORT, мы можем легко передавать конфигурации между различными экземплярами ShardingSphere-Proxy, упрощая поддержание согласованности в нашей системе и гарантируя, что наши конфигурации всегда актуальны и точны.
Подготовить новую базу данных
USE shardingsphere; DROP DATABASE sharding_db; CREATE DATABASE sharding_db; EXPORT DATABASE CONFIGURATION FROM sharding_db;
Пример выполнения
mysql> USE shardingsphere; Database changed mysql> DROP DATABASE sharding_db; Query OK, 0 rows affected (0.02 sec) mysql> CREATE DATABASE sharding_db; Query OK, 0 rows affected (0.02 sec) mysql> EXPORT DATABASE CONFIGURATION FROM sharding_db; +----------------------------+ | result | +----------------------------+ | databaseName: sharding_db | +----------------------------+ 1 row in set (0.01 sec)
Сделав это, мы создали новую логическую базу данных sharding_db, которая не содержит никакой информации о конфигурации.
Импорт логической базы данных
USE sharding_db; IMPORT DATABASE CONFIGURATION FROM FILE '/Users/xx/sharding_db.yaml';
Пример выполнения
mysql> USE sharding_db; Database changed mysql> IMPORT DATABASE CONFIGURATION FROM FILE '/Users/xx/sharding_db.yaml'; Query OK, 0 rows affected (1.06 sec)
Используя синтаксис IMPORT DATABASE CONFIGURATION, мы можем легко восстановить экспортированную логическую конфигурацию базы данных в онлайн-экземпляр ShardingSphere-Proxy. Этот процесс быстрый и простой, что позволяет нам поддерживать наши конфигурации в актуальном состоянии и обеспечивает согласованность всей нашей системы.
Чтобы подтвердить, что импорт прошел успешно, мы можем использовать операторы SHOW DATABASES и EXPORT DATABASE CONFIGURATION. Эти операторы позволяют нам проверить состояние наших конфигураций и убедиться, что все импортировано правильно.
В целом, комбинация операторов EXPORT, IMPORT, и SHOW обеспечивает мощный набор инструментов для управления и поддержки конфигураций базы данных с помощью ShardingSphere-Proxy. Эффективно используя эти инструменты, мы можем гарантировать, что наши конфигурации всегда точны и актуальны, что позволяет нам создавать более надежные и надежные системы.
ПРЕОБРАЗОВАТЬ КОНФИГУРАЦИЮ YAML
Синтаксис CONVERT YAML CONFIGURATION — это мощный инструмент, который позволяет нам преобразовывать экспортированные конфигурации YAML в DistSQL, упрощая пользователям управление базами данных и их обслуживание. Эта функция особенно полезна, когда нам нужно перенести конфигурации между разными средами.
Чтобы продемонстрировать эту функциональность, давайте преобразуем файл sharding_db.yaml, который мы экспортировали ранее, с помощью оператора EXPORT. Преобразовав YAML в DistSQL, мы можем перенести конфигурацию с помощью SQL-клиента, что удобнее, чем копирование файлов для импорта.
Синтаксис CONVERT YAML CONFIGURATION позволяет нам легко преобразовать файл YAML в DistSQL. Затем мы можем использовать полученные операторы для переноса конфигурации в новую среду. Этот процесс быстрый и простой, что позволяет нам более эффективно управлять нашими конфигурациями.
В целом синтаксис CONVERT YAML CONFIGURATION является ценным инструментом для управления и поддержки конфигураций базы данных с помощью ShardingSphere-Proxy. Эффективно используя этот синтаксис, мы можем упростить процесс миграции конфигураций и гарантировать, что наши базы данных всегда актуальны и точны.
CONVERT YAML CONFIGURATION FROM FILE '/Users/xx/sharding_db.yaml';
Пример выполнения
mysql> CONVERT YAML CONFIGURATION FROM FILE '/Users/xx/sharding_db.yaml';
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| dist_sql |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| CREATE DATABASE sharding_db;
USE sharding_db;
REGISTER STORAGE UNIT ds_1 (
URL='jdbc:mysql://127.0.0.1:3306/demo_ds_1?serverTimezone=UTC&useSSL=false',
USER='root',
PASSWORD='123456',
PROPERTIES('minPoolSize'='1', 'connectionTimeoutMilliseconds'='30000', 'maxLifetimeMilliseconds'='2100000', 'readOnly'='false', 'idleTimeoutMilliseconds'='60000', 'maxPoolSize'='10')
), ds_0 (
URL='jdbc:mysql://127.0.0.1:3306/demo_ds_0?serverTimezone=UTC&useSSL=false',
USER='root',
PASSWORD='123456',
PROPERTIES('minPoolSize'='1', 'connectionTimeoutMilliseconds'='30000', 'maxLifetimeMilliseconds'='2100000', 'readOnly'='false', 'idleTimeoutMilliseconds'='60000', 'maxPoolSize'='10')
);
CREATE SHARDING TABLE RULE t_order (
STORAGE_UNITS(ds_0,ds_1),
SHARDING_COLUMN=order_id,
TYPE(NAME='mod', PROPERTIES('sharding-count'='4')),
KEY_GENERATE_STRATEGY(COLUMN=order_id, TYPE(NAME='snowflake'))
);
|
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)
Заключение
Таким образом, мы изучили функции и преимущества DistSQL в Apache ShardingSphere, включая возможность динамического управления ресурсами и правилами с помощью синтаксиса конфигурации Export, Import и Convert YAML.
Используя эти функции, пользователи могут легко выполнять резервное копирование, миграцию и управление конфигурациями в своих распределенных средах SQL.
Для получения дополнительной информации о DistSQL обратитесь к официальной документации [1] и нашему репозиторию GitHub [5].
Если у вас есть какие-либо вопросы или отзывы об Apache ShardingSphere, не стесняйтесь задавать их в списке проблем GitHub или присоединяйтесь к нашему каналу Slack для обсуждения. Мы надеемся, что эта статья была для вас полезной и информативной.
Рекомендации
[1] DistSQL documatation: https://shardingsphere.apache.org/document/5.3.1/cn/user-manual/shardingsphere-proxy/distsql/ [2] SHOW SHARDING TABLE RULE: https://shardingsphere.apache.org/document/5.3.1/cn/user-manual/shardingsphere-proxy/distsql/syntax/rql/rule-query/sharding/show-sharding-table-rule/ [3] SHOW READWRITE_SPLITTING RULE: https://shardingsphere.apache.org/document/5.3.1/cn/user-manual/shardingsphere-proxy/distsql/syntax/rql/rule-query/readwrite-splitting/show-readwrite-splitting-rule/ [4] Using the ShardingSphere-Proxy binary release package: https://shardingsphere.apache.org/document/5.3.1/cn/user-manual/shardingsphere-proxy/startup/bin/ [5] GitHub issue list: https://github.com/apache/shardingsphere/issues
