yuqi1129 commented on issue #10472:
URL: https://github.com/apache/gravitino/issues/10472#issuecomment-4086940788
@youngyjd
Thanks for raising this request. Before we decide whether Gravitino should
introduce separate JDBC read/write endpoints, could you share a bit more about
your production setup?
Specifically, have you already evaluated or used MySQL read/write middleware
such as Mycat, Apache ShardingSphere, or Vitess? If yes, it would help a lot to
understand your exact use case: for example, read-heavy analytics with
occasional writes, cross-region disaster recovery, tenant isolation, online
scaling, or strict read-after-write consistency requirements. Also, what are
the current pain points with your existing solution (if any): routing
flexibility, failover behavior, operational overhead, consistency guarantees,
or observability?
We ask this because these middleware layers already provide many mature
capabilities that overlap with “separate read/write JDBC addresses,” often with
better operational control:
- Transparent read/write splitting and routing policies
- Automatic failover and topology awareness for replicas/primaries
- Traffic governance, throttling, and connection management
- Sharding/partitioning support (especially ShardingSphere/Vitess)
- Observability and SQL governance (audit, metrics, tracing integration)
- Centralized policy management, so applications stay simpler and use one
logical endpoint
From a platform perspective, if middleware can solve the requirement, users
may get a more reusable and battle-tested path than adding DB-topology-specific
knobs into each connector. That said, we’re very open to improving Gravitino if
there are clear gaps that middleware cannot cover in your scenario.
If you can share your architecture and expected behavior (especially
consistency and failover expectations), we can evaluate whether this should be
handled by middleware guidance/documentation, connector enhancement, or both.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
