go-admingo-admin
  • Guide
  • Development
    • Advanced
    • Commands
  • Advanced
  • Help
  • GitHub
  • Changelog
⌘ K
Config Reference
Sharding by Business
Multi-Tenancy
Last updated:
Open-source MIT Licensed | Copyright © 2020-present
Powered by go-admin-team
‌
‌
‌
‌

Sharding by Business

As a project grows, a common approach is to split different business data across different databases. This usually means maintaining several database connections in code, and remembering which table belongs to which one.

go-admin handles this using GORM's DBResolver: sharding rules live in the config file and route automatically by table, while business code keeps using e.Orm as usual, with no need to be aware the connections exist.

Here's a sharding config example:

yml
database:
driver: mysql
source: root:password@tcp(************.mysql.rds.aliyuncs.com:3306)/dbname1?charset=utf8mb4&parseTime=True&loc=Local&timeout=10000ms
registers:
- source: root:password@tcp(************.mysql.rds.aliyuncs.com:3306)/dbname1?charset=utf8mb4&parseTime=True&loc=Local&timeout=10000ms
replicas:
- 'root:password@tcp(************.mysql.rds.aliyuncs.com:3306)/dbname2?charset=utf8mb4&parseTime=True&loc=Local&timeout=10000ms'
tables:
- 'tb_order'
- 'tb_user'

The config has three connection addresses, each with a distinct role:

LocationRole
database.sourceThe default connection. Any table not matched by a sharding rule uses this
registers[].sourceThe primary for this group, handling writes
registers[].replicasThe replicas for this group, handling reads
registers[].tablesThe list of table names this group applies to

tables is what drives the routing: tables listed there (tb_order and tb_user in the example) automatically use that group's connection; everything else keeps using the default connection. No changes needed on the business-code side.

WARNING

In the current implementation, a sharding group's replicas are used for reads only. Writes, deletes, and updates against a sharded group aren't supported yet — writes still land on the primary.

Keep this in mind when designing a sharding scheme: it fits tables that are read-heavy and can tolerate read/write splitting, not ones that need writes completed on an isolated database.