Skip to main content

3 posts tagged with "pisanix"

View All Tags

· 5 min read
Maxwell Miao
Jiandong Wu
Bo Wang
Zhuo Li

Database Mesh

Database Mesh-oriented solutions for an easy-to-use, good-to-use, and practical user experience.

Pisanix version 0.2.0 was recently released. The newly released one supports dynamic read/write splitting. More details below.

Introducing dynamic read/write splitting

Introduction

Read/write splitting is one of the most commonly used solutions for MySQL's high availability. It improves query performance and reduces server load in practical scenarios. On top of the static rules of v0.1.1, dynamic read/write splitting is added in this release.

Read/write splitting rules need to be configured when it comes to splitting with dynamic awareness. Pisa-Proxy performs SQL routing according to the rules. As shown in Figure 1.1, the Pisa-Proxy backend will start four monitors to sense the backend cluster status.

Monitor Reconcile will calculate and aggregate the data reported by the Monitor and draw the final state of the backend cluster. Then Monitor Reconcile sends the state information to RulesMatch through the channel. RulesMatch dynamically adjusts the backend data source list once it receives the message.

The concepts included above are:

  • Node: Backend database node.
  • RulesMatch: RulesMatch engine matches with the SQL query statements received by Pisa-Proxy based on the written rule set.
  • TargetRole: A TargetRole group matched by the RulesMatch engine. Each TargetRole group may contain one or more nodes.
  • LoadBalance: The load balance module selects an appropriate node from the TargetRole group according to the corresponding algorithm.
  • TargetInstance: Nodes selected by the LoadBalance module.
  • Discovery: Discovery type, which corresponds to the high availability strategy used by the backend data source, such as MHA, RDS, MGR, etc. The newly released version mainly supports MHA.
  • Monitor: It refers to the backend detector module of Pisa-Proxy, which mainly relies on four kinds of Monitors in MHA.
    • Connect Monitor: detect database connectivity.
    • Ping Monitor: detect whether the database is healthy.
    • Replication Lag Monitor: detect the latency status of primary-secondary replication.
    • Read Only Monitor: detect the roles of primary-secondary databases.

Read/write splitting configuration

The configuration mode of dynamic read/write splitting is the same as that of the static one. The configuration items of dynamic read/write splitting are as follows:

ParameterTypeDependency or notDefault ValueDescription
userstringYesNoneDetector module checks the username of SQL statements.
passwordstringYesNoneDetector module checks the password of SQL statements.
monitor_periodu64Yes1000The period (ms) by which detector module updates and senses the backend data source status.
connect_periodu64Yes1000Connect Monitor detection period (ms)
connect_timeoutu64Yes6000Connect Monitor detection timeout (ms)
connect_failure_thresholdu64Yes1Number of retries when Connect Monitor detection fails
ping_periodu64Yes1000Ping Monitor detection period (ms)
ping_timeoutu64Yes6000Ping Monitor detection timeout (ms)
ping_failure_thresholdu64Yes1Number of retries when Ping Monitor detection fails.
replication_lag_periodu64Yes1000Replication Lag Monitor detection period (ms)
replication_lag_timeoutu64Yes6000Replication Lag Monitor detection timeout (ms)
replication_lag_failure_thresholdu64Yes1Number of retries when Replication Lag Monitor detection fails.
max_replication_lagu64Yes10000User-defined maximum primary/secondary latency threshold (ms)
read_only_periodu64Yes1000Read Only detection period (ms)
read_only_timeoutu64Yes6000Read Only detection timeout (ms)
read_only_failure_thresholdu64Yes3Number of retries when Read Only Monitor detection fails.

CRD configuration sample:

apiVersion: core.database-mesh.io/v1alpha1
kind: TrafficStrategy
metadata:
name: catalogue
namespace: demotest
spec:
selector:
matchLabels:
source: test
loadBalance:
readWriteSplitting:
dynamic:
defaultTarget: readwrite
discovery:
masterHighAvailability:
connectionProbe:
failureThreshold: 3
periodMilliseconds: 1000
timeoutMilliseconds: 6000
monitorPeriod: 1000
pingProbe:
failureThreshold: 3
periodMilliseconds: 1000
timeoutMilliseconds: 6000
readOnlyProbe:
failureThreshold: 3
periodMilliseconds: 1000
timeoutMilliseconds: 6000
replicationLagProbe:
failureThreshold: 3
maxReplicationLag: 3
periodMilliseconds: 1000
timeoutMilliseconds: 6000
user: monitor
password: monitor
rules:
- algorithmName: roundrobin
name: write-rule
regex:
- ^insert
target: readwrite
type: regex
- algorithmName: roundrobin
name: read-rule
regex:
- ^select
target: read
type: regex

Pisanix v0.2.0 Description

New features

  • Pisa-Controller
    • Support dynamic read/write splitting in the TrafficStrategy CRD ReadWriteSplitting field #208
  • Pisa-Proxy
    • Support dynamic read/write splitting #204
    • Add the sub-command: daemonsidecar #190

Enhancements

  • Refactor config files of Pisa-Proxy #182
  • Complete the SHOW SQL statement parsing #183
  • Add code coverage checks to Pisa-Controller #192
  • Enable reconnecting when backend data source fails to be connected #215

Improvements

  • Pisa-Controller
    • Fix webhook tls #221
  • Pisa-Proxy
    • Fix the request failure to switch MySQL authentication #170
    • Handle exceptions of EOF package of MySQL protocol #166
    • Fix the Charset character set #154
    • Fix the environment variables injection #223

Others

There are 62 PRs in this release. Thanks to the following contributors:

  • mlycore
  • xuanyuan300
  • wbtlb
  • windghoul
  • lltgo
  • tuichenchuxin
  • dongzl

🔗Download link: https://github.com/database-mesh/pisanix/releases/tag/v0.2.0

Community Call

Building an open source community needs help from everywhere, no matter it's code or documentation, issues or pull requests, community thanks all of your efforts.

At present, there are some ways to join the community:

Mailing Listhttps://groups.google.com/g/database-mesh
Dev Meetings (Starting Feb 16th, 2022), Bi-weekly Wednesday 9:00AM PSThttps://meet.google.com/yhv-zrby-pyt
Dev Meetings APAC Friendly (Starting April 27th, 2022), Bi-weekly APAC Wednesday 9:00PM GMT+8https://meeting.tencent.com/dm/6UXDMNsHBVQO
Wechat Brokerpisanix
Slackhttps://join.slack.com/t/databasemesh/shared_invite/zt-19rhvnxkz-USjZ~am~ghd_Q0q~8bAJXA
Meetings Noteshttps://bit.ly/39Fqt3x

Feel free to talk !

· 5 min read
Maxwell Miao
Jiandong Wu
Bo Wang
Zhuo Li

Pisanix v0.1.1 is now released three weeks after Pisanix v0.1.0 was released. This new version supports read/write splitting and fixes some problems of the old version.

Pisanix v0.1.1 Description

New Features

  • Pisa -Controller
    • Add ReadWriteSplitting configuration to TrafficStrategy CRD
  • Pisa-Proxy
    • Introduce MetricsManager and MetricsCollector, laying a foundation for processing Metrics later.
    • Add sql_under_processingmetric as Gauge, referring to the number of SQL under processing
    • Support static read-write splitting rules
    • Support TCL statement parsing
    • Add show databases,show tables, and create database statements parsing

Improvements

  • Pisa-Controller
    • Fix ApiService json parsing error, resulting in that namespace cannot be deleted. #34
    • Support Regex array for CircuitBreak, ConcurrencyControl and ReadWriteSplitting. #123 #124
    • Rename sidecar name to pisa-proxy. #72
    • Add default host as 0.0.0.0 and port as 3306 to MySQL type VirtualDatabase. #68
    • Add server_version to Pisa-Proxy, referring to the MySQL version. #111
  • Pisa-Proxy
    • Support default admin port as 5591, which can be used to obtain metrics. #121
    • Fix the packet processing exceptions when the PREPARE statement is too long. #73
    • Fix SQL parsing ability. #98 #104

Others

Introducing Read-Write Splitting

Read-write splitting is one of the most commonly used MySQL solutions in the industry. In actual scenarios, it can improve query performance and reduce server load. The general structure is as follows:

Read-write splitting is part of the traffic strategies in Pisa-Proxy.

Currently, Pisa-Proxy supports two kinds of read-write splitting solutions:

  • Static read-write splitting: no backend awareness of database role change.
  • Dynamic read-write splitting (coming): backend awareness of the primary and secondary databases change.

Currently, both solutions require the configuration of read-write splitting rules. The read-write splitting rule refers to that Pisa-Proxy needs to match the SQL statement queried with the configured rule. If the match succeeds, the SQL statement is routed to the corresponding node according to the rule. If the match fails, the SQL statement is routed to the configured default node.

There are several concepts included:

  • Node: the backend database node.
  • RulesMatch: The RulesMatch engine matches the SQL query statements received by Pisa-Proxy by the compiled rule set.
  • TargetRole: The TargetRole group matched by the rule matching engine. Each TargetRole group may contain one or more nodes.
  • LoadBalance: The load balancer module will select an appropriate node from the TargetRole group according to corresponding algorithms.
  • TargetInstance: nodes selected from the LoadBalance module.

The implementation logic is as follows:

Read-Write Splitting Configuration

PropertyValue TypeDependency or notDefault ValueImplication
staticobjectNoNoStatic R/W splitting type
dynamicobjectNoNoDynamic R/W splitting configuration

Static read-write splitting configuration

PropertyValue TypeDependency or notDefault ValueImplication
defaultTargetenumNoNoThe target group of default routing
rulesarray{rule}YesNoRead-write splitting rule

Read-Write Splitting Rule Description

Currently, read-write splitting rules can only be matched through RegEx. The rule configuration description is as follows:

PropertyValue TypeDependency or notDefault ValueImplication
namestringYesNoRule name
typestringYesNoThe routing type belongs to RegEx, and the value here is regex.
regexarray{string}YesNoSpecific regex, used to match SQL statements
targetenumYesNoThe TargetRole group that is routed to, corresponding to the value of database-mesh.io/role in DatabaseEndpoint Annotations.
algorithmNameenumYesNoThe name of the load balancer algorithm used for the machine lists that are routed to the role group.

Note: the Enum values above are respectively:

  • TargetRole Enum value
    • read
    • readwrite
  • algorithName Enum value
    • random
    • roundrobin

Sample

The configuration of a complete TrafficStrategy CRD is as follows:

apiVersion: core.database-mesh.io/v1alpha1
kind: TrafficStrategy
metadata:
name: test
namespace: default
spec:
selector:
matchLabels:
source: test
loadBalance:
readWriteSplitting:
static:
defaultTarget: read # or readwrite
rules:
- name: read-rule
type: regex
regex:
- "^select"
target: read # readwrite
algorithmName: random # lb algorithm
- name: write-rule
type: regex
regex:
- "^insert"
target: readwrite
algorithmName: roundrobin

The configuration of a complete DatabaseEndpoint CRD is as follows:

apiVersion: core.database-mesh.io/v1alpha1
kind: DatabaseEndpoint
metadata:
annotations:
database-mesh.io/role: read # or readwrite
labels:
source: test
name: mysql
namespace: default
spec:
database:
MySQL:
db: test
host: mysql.default
password: root
port: 3306
user: root

Community Call

The new version contains 47 PRs and thanks to all the contributors:

  • mlycore
  • xuanyuan300
  • wbtlb
  • tuichenchuxin
  • windghoul
  • TeslaCN

🔗Download link:https://github.com/database-mesh/pisanix/releases/tag/v0.1.1

Building an open source community needs help from everywhere, no matter it's code or documentation, issues or pull requests, community thanks all of your efforts.

At present, there are some ways to join the community:

Mailing Listhttps://groups.google.com/g/database-mesh
Dev Meetings (Starting Feb 16th, 2022), Bi-weekly Wednesday 9:00AM PSThttps://meet.google.com/yhv-zrby-pyt
Dev Meetings APAC Friendly (Starting April 27th, 2022), Bi-weekly APAC Wednesday 9:00PM GMT+8https://meeting.tencent.com/dm/6UXDMNsHBVQO
Wechat Brokerpisanix
Slackhttps://join.slack.com/t/databasemesh/shared_invite/zt-19rhvnxkz-USjZ~am~ghd_Q0q~8bAJXA
Meetings Noteshttps://bit.ly/39Fqt3x

Feel free to talk !

· 6 min read
Maxwell Miao
Jiandong Wu
Bo Wang
Zhuo Li

June 6th, 2022, Pisanix announced its first release v0.1.0.

As the first open source project of Database Mesh 2.0, Pisanix follows the core concepts that building an efficient and programmable database governance experience in cloud native era from the very beginning. This means Pisanix really hope to help Database Mesh grow to an achievable framework.

Who is Pisanix ?

Pisanix is the open source solution for Database Mesh, which composes of three different components: Pisa-Controller, Pisa-Proxy and Pisa-Daemon(Coming Soon), and is sponsored by SphereEx.

Written with Golang and Rustlang, Pisanix is going to build an experience that support SQL aware traffic management, runtime oriented resource programming and Database Reliability Engineering.

Like classical Service Mesh deployment pattern, Pisanix also contains a control-plane which is Pisa-Controller, and two data-plane which is Pisa-Proxy and Pisa-Daemon.

Pisa-Controller

Act as the required part of Pisanix, Pisa-Controller is responsible for:

  • Sidecar injection: Using MutatingAdmissionWebhook inject sidecar to selected Pods
  • Pisa-Proxy configuration conversion: Retrieve service discovery, load balance, concurrency control, SQL circuit break configs in CRDs and convert them to Pisa-Proxy configurations
  • Pisa-Daemon configuration conversion: Retrieve traffic QoS configs in CRDs and convert them to Pisa-Daemon configurations

Pisa-Proxy

Pisa-Proxy is the core part of Pisanix, working as a high-performance proxy for different protocols. Currently supports:

  • SQL traffic control: Traffic load balance, concurrency control and
  • Access Control: Fine-grained access control rule according to user and data relationship
  • Circuit break: Reject high risk SQL execution
  • Observability: Metrics about SQL processing: latency、throughput

Pisa-Daemon

Pisa-Daemon is optional and will be release soon. Features like runtime resource management, such as providing traffic QoS with the help of eBPF is what Pisa-Daemon care about.

What does Maintainers say ?

Maxwell: "Thanks to the cloud native ecosystem and all of the open source projects. We have learned a lot from the community, and now we get the chance to do something, that is Pisanix. The core motivation of Pisanix is to help, help developers, SREs and DBAs, and also help databases. This makes Pisanix a very meaningful infrastructure software. Thanks for your attention and support."

Jiandong: "Pisanix is a concrete practice of the Database Mesh idea. It is a project with great potential. As a nascent community, I hope everyone can participate and witness our growth together."

Bo: "Pisanix is a set of governance frameworks in the database DRE project. This framework is all-encompassing. It not only provides users in different scenarios such as developer-facing and DBA, but also provides rich thinking in the field of software design for colleagues in different area. Friends are very welcomed to join the community and build it together."

Zhuo: "As an emerging project that implements DRE ideas and realizes database-mesh design. Pisanix provides developers, DBAs, and SREs with unlimited possibilities. There will be more designs and inspirations presented to you in the future. I wish everyone will continue to pay attention, build together, and complete this idea."

What's new in v0.1.0

This is the first release of Pisanix.

Features

Pisa-Controller

Setup
  • Label-based sidecar injection
Configuration conversion
  • Kubernetes CRD conversion to Pisa-Proxy configurations, including VirtualDatabase, TrafficStrategy, DatabaseEndpoint

Pisa-Proxy

Setup
  • Retrieve configuration from Pisa-Controller
Runtime
  • Support multiple proxy runtimes speaking MySQL protocol
  • Support connection pool and basic loadbalancing strategy
  • Support Yacc based SQL parser: SELECT, INSERT, UPDATE, DELETE, PREPARE, EXECUTE, BEGIN and SET.
  • Support Regex based SQL circuit break
  • Support Regex based SQL concurrency control
Observability
  • Supoort basic observability
    • sql_processed_total
    • sql_processed_duration

What can I do with Pisanix ?

Database Mesh designs with these building blocks and terminology below:

  • Virtual Database: A database endpoint could be consumed by application
  • Traffic Strategy: Various strategy for database traffic, such as load balancing, sharding, rate limit and circuit breaker
  • Access Control: Providing fine-grained admission mechanism
  • Security Claim: Claim for security enhance mechanism, such as encryption
  • Audit Request: Request for user operation audit
  • Observability: Provide a config for observability of databases
  • Event Bus: Sink database change events to external systems
  • QoS Claim: Porviding several object guarantee for databases
  • Backup Job: Database backup jobs
  • Schema Pipeline: Using pipeline for versioned schema changing

Pisanix introduced CustomResourceDefinition including VirtualDatabase, Traffic Strategy and DatabaseEndpoint as workloads. And this is a example of Weaveworks Socks-shop.

VirtualDatabase

VirtualDatabase is the root concept for every database governance actions in Pisanix. To developers, VirtualDatabase is represented as a database endpoint. For DBAs, VirtualDatabase is some kind of a logical database, so they need to provide some traffic strategy and bind it to a real backend database endpoint.

apiVersion: core.database-mesh.io/v1alpha1
kind: VirtualDatabase
metadata:
name: catalogue
namespace: default
spec:
services:
- databaseMySQL: # Declare a MySQL database
db: socksdb # Declare the schema
host: 127.0.0.1
port: 3306
user: catalogue_user
password: default_password
name: mysql
trafficStrategy: catalogue # The target traffic strategy for the database

TrafficStrategy

TrafficStrategy defines how the SQL requests will be routed to the real database endpoint, strategies like loadbalance, concurrency control, circuit break are supported now.

apiVersion: core.database-mesh.io/v1alpha1
kind: TrafficStrategy
metadata:
name: catalogue
namespace: default
spec:
loadBalance:
simpleLoadBalance: # A simple load balance strategy
kind: random # support random as selection algorithm
selector:
matchLabels: # Declare the label selector to choose the backend database
source: catalogue

DatabaseEndpoint

Database Endpoint refers to a real database endpoint, no matter it's endpoint of AWS RDS, a MySQL instance, or ShardingSphere. Virtual Database consumes several DatabaseEndpoint with TrafficStrategy.

apiVersion: core.database-mesh.io/v1alpha1
kind: DatabaseEndpoint
metadata:
name: catalogue-db
namespace: default
spec:
database:
MySQL: # Declare the database type MySQL
db: socksdb
host: cataloguedb.codtynlacssn.rds.cn-northwest-1.amazonaws.com.cn
port: 3306
user: root
password: fake_password

Now the working flow is like :

  1. Developers submit their need of database as VirtualDatabase
  2. DBAs create and bind TrafficStrategy with DatabaseEndpoint
  3. SREs add labels pisanix.io/inject=enabled to the application and update the configuration with credentials stored in VirtualDatabase.

After the application is running, we can checkout the Socks-shop website as below:

How about the next steps ?

As we can see that Pisanix is very young, and have a definitely long way to run. In the next, we will first enhance the ability of traffic governance, like adding data sharding, data access behavior auditing, runtime resource Qos, etc. And we also continuously improving the performance and operability of Pisanix. More extensions mechanism like plugins will be in the future, help users to build their own solution very easily.

Community Call

Building an open source community needs help from everywhere, no matter it's code or documentation, issues or pull requests, community thanks all of your efforts.

At present, there are some ways to join the community:

Mailing Listhttps://groups.google.com/g/database-mesh
Dev Meetings (Starting Feb 27th, 2022), Bi-weekly Wednesday 9:00AM PSThttps://meet.google.com/yhv-zrby-pyt
Dev Meetings APAC Friendly (Starting April 27th, 2022), Bi-weekly APAC Wednesday 9:00PM GMT+8https://meeting.tencent.com/dm/6UXDMNsHBVQO
Wechat Brokerpisanix
Slackhttps://join.slack.com/t/databasemesh/shared_invite/zt-19rhvnxkz-USjZ~am~ghd_Q0q~8bAJXA
Meetings Noteshttps://bit.ly/39Fqt3x

Feel free to talk !