ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Goal: configure alerts for VTGate context deadline exceeded errors to capture sustained latency spikes while avoiding noise from transient timeouts. Constraint: need to rely on VTGate latency histogram and error rate metrics; uncertainty about whether default thresholds should be static or auto‑adjusted based on traffic patterns, as documentation does not sp
In a Vitess cluster, vtgate terminates the client MySQL protocol while vttablet brokers queries to a backing MySQL instance using its own configured application and administrative accounts. When a backend MySQL account is subject to password expiration or is scoped to a least-privilege role, the failure mode at the vtgate-to-vttablet boundary is not obvious:
Pagination across a sharded Vitess keyspace forces a choice between offset-based paging and keyset bounds, but VTGate does not resolve that choice automatically. When a scatter query carries LIMIT and OFFSET, VTGate pushes both down to each shard and merges the results, so a page at offset n causes every shard to read roughly n + limit rows before the merge.
Symptom When a tablet becomes unreachable during a single-statement write (INSERT, UPDATE, DELETE) outside an explicit transaction, VTGate may retry the statement against a healthy tablet after failover. If the original attempt already committed but the client never received confirmation, the retry applies the same write a second time. Constraints Vitess can
vitess