Registry Center

Motivation

  • Centralized configuration: more and more running examples have made it hard to manage separate configurations and asynchronized configurations can cause serious problems. Concentrating them in the configuration center can make the management more effective.

  • Dynamic configuration: distribution after configuration modification is another important capability of configuration center. It can support dynamic switch between data sources and rule configurations.

  • Hold all ephemeral status data dynamically generated in runtime(such as available proxy instances, disabled datasource instances etc).

  • Disable the access to replica database and the access of application. Governance still has many functions(such as flow control) to be developed.

Data Structure in Registry Center

Under defined namespace, rules, props and metadata nodes persist in YAML, modifying nodes can dynamically refresh configurations. status node persist the runtime node of database access object, to distinguish different database access instances.

  1. namespace
  2.    ├──rules                                     # Global rule configuration
  3.    ├──props                                     # Properties configuration
  4.    ├──metadata                                  # Metadata configuration
  5.    ├      ├──${schema_1}                        # Schema name 1
  6.    ├      ├      ├──dataSources                 # Datasource configuration
  7.    ├      ├      ├──rules                       # Rule configuration
  8.    ├      ├      ├──schema                      # Table configuration
  9.    ├      ├──${schema_2}                        # Schema name 2
  10.    ├      ├      ├──dataSources                 # Datasource configuration
  11.    ├      ├      ├──rules                       # Rule configuration
  12.    ├      ├      ├──schema                      # Table configuration
  13.    ├──status
  14.    ├    ├──compute_nodes
  15.    ├    ├     ├──online
  16.    ├    ├     ├     ├──${your_instance_ip_a}@${your_instance_port_x}
  17.    ├    ├     ├     ├──${your_instance_ip_b}@${your_instance_port_y}
  18.    ├    ├     ├     ├──....
  19.    ├    ├     ├──circuit_breaker
  20.    ├    ├     ├     ├──${your_instance_ip_c}@${your_instance_port_v}
  21.    ├    ├     ├     ├──${your_instance_ip_d}@${your_instance_port_w}
  22.    ├    ├     ├     ├──....
  23.    ├    ├──storage_nodes
  24.    ├    ├     ├──disable
  25.    ├    ├     ├      ├──${schema_1.ds_0}
  26.    ├    ├     ├      ├──${schema_1.ds_1}
  27.    ├    ├     ├      ├──....
  28.    ├    ├     ├──primary
  29.    ├    ├     ├      ├──${schema_2.ds_0}
  30.    ├    ├     ├      ├──${schema_2.ds_1}
  31.    ├    ├     ├      ├──....

/rules

global rule configurations， including configure the username and password for ShardingSphere-Proxy.

  1. - !AUTHORITY
  2. users:
  3.   - root@%:root
  4.   - sharding@127.0.0.1:sharding
  5. provider:
  6.   type: ALL_PRIVILEGES_PERMITTED

/props

Properties configuration. Please refer to Configuration Manual for more details.

  1. kernel-executor-size: 20
  2. sql-show: true

/metadata/${schemeName}/dataSources

A collection of multiple database connection pools, whose properties (e.g. DBCP, C3P0, Druid and HikariCP) are configured by users themselves.

  1. ds_0: 
  2.   dataSourceClassName: com.zaxxer.hikari.HikariDataSource
  3.   props:
  4.     url: jdbc:mysql://127.0.0.1:3306/demo_ds_0?serverTimezone=UTC&useSSL=false
  5.     password: null
  6.     maxPoolSize: 50
  7.     connectionTimeoutMilliseconds: 30000
  8.     idleTimeoutMilliseconds: 60000
  9.     minPoolSize: 1
  10.     username: root
  11.     maxLifetimeMilliseconds: 1800000
  12. ds_1: 
  13.   dataSourceClassName: com.zaxxer.hikari.HikariDataSource
  14.   props:
  15.     url: jdbc:mysql://127.0.0.1:3306/demo_ds_1?serverTimezone=UTC&useSSL=false
  16.     password: null
  17.     maxPoolSize: 50
  18.     connectionTimeoutMilliseconds: 30000
  19.     idleTimeoutMilliseconds: 60000
  20.     minPoolSize: 1
  21.     username: root
  22.     maxLifetimeMilliseconds: 1800000

/metadata/${schemeName}/rules

Rule configurations, including sharding, readwrite-splitting, data encryption, shadow DB configurations.

  1. - !SHARDING
  2.   xxx
  4. - !READWRITE_SPLITTING
  5.   xxx
  7. - !ENCRYPT
  8.   xxx

/metadata/${schemeName}/schema

Dynamic modification of metadata content is not supported currently.

  1. tables:                                       # Tables
  2.   t_order:                                    # table_name
  3.     columns:                                  # Columns
  4.       id:                                     # column_name
  5.         caseSensitive: false
  6.         dataType: 0
  7.         generated: false
  8.         name: id
  9.         primaryKey: trues
  10.       order_id:
  11.         caseSensitive: false
  12.         dataType: 0
  13.         generated: false
  14.         name: order_id
  15.         primaryKey: false
  16.     indexs:                                   # Indexes
  17.       t_user_order_id_index:                  # index_name
  18.         name: t_user_order_id_index
  19.   t_order_item:
  20.     columns:
  21.       order_id:
  22.         caseSensitive: false
  23.         dataType: 0
  24.         generated: false
  25.         name: order_id
  26.         primaryKey: false

/status/compute_nodes

It includes running instance information of database access object, with sub-nodes as the identifiers of currently running instance, which consist of IP and PORT. Those identifiers are temporary nodes, which are registered when instances are on-line and cleared when instances are off-line. The registry center monitors the change of those nodes to govern the database access of running instances and other things.

/status/storage_nodes

It is able to orchestrate replica database, delete or disable data dynamically.

Dynamic Effectiveness

Modification, deletion and insertion of relevant configurations in the config center will immediately take effect in the producing environment.

Operation Guide

Circuit Breaker

Write DISABLED (case insensitive) to IP@PORT to disable that instance; delete DISABLED to enable the instance.

Zookeeper command is as follows:

  1. [zk: localhost:2181(CONNECTED) 0] set /${your_zk_namespace}/status/compute_nodes/circuit_breaker/${your_instance_ip_a}@${your_instance_port_x} DISABLED

Disable Replica Database

Under readwrite-splitting scenarios, users can write DISABLED (case insensitive) to sub-nodes of data source name to disable replica database sources. Delete DISABLED or the node to enable it.

Zookeeper command is as follows:

  1. [zk: localhost:2181(CONNECTED) 0] set /${your_zk_namespace}/status/storage_nodes/disable/${your_schema_name.your_replica_datasource_name} DISABLED