Skip to content

server-zd v0.1.24

Choose a tag to compare

View all tags
@longquanzheng longquanzheng released this 09 Nov 20:18
server-zd/v0.1.24
85de350
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Breaking Changes

None. Existing configurations keep using S3.

server-zd v0.1.24

db9 object storage provider (#1415)

serve can now store its durable state in db9 instead of S3. db9 is a PostgreSQL-compatible database. The state covers command logs, lease and cluster metadata, snapshots, blobs, and history objects.

  • Enable it with objectStore.provider: db9 and set the connection string in DEX_ZD_DB9_CONNECTION_STRING, outside YAML. The connection string is never serialized or logged.
  • objectStore.bucket is a logical namespace and objectStore.prefix scopes keys within it. objectStore.db9PoolSize (default 8, 1–64) and objectStore.db9RequestTimeout (default 10s per SQL request) tune the connection pool.
  • On startup the server creates two tables, dex_object_metadata and dex_object_chunks, so the SQL user needs DDL permission. Objects are stored in 256 KiB chunks. Each write commits in one transaction with ETag compare-and-swap.
  • dev and local reject db9; use serve. An explicit hardDeleteStore can still point at S3.
  • Existing S3 state is not migrated. Start a new namespace for db9.
  • Durability and consistency come from the database. It must provide durable atomic transactions, row locks, and strongly consistent reads. Large objects are subject to database transaction limits. Throughput and database failover have not been load tested.
  • See server-zd/config/dex-server-zd.db9.example.yaml and the db9 section of the server-zd README.

Testing

Server ZD CI runs the provider's conformance and db9 tests against PostgreSQL 16 when a pull request carries the db9-tests label.

Assets 7
Loading