-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFD 203 - Database Health Checks #52400
base: master
Are you sure you want to change the base?
Conversation
4b5a393
to
2372383
Compare
2372383
to
a4cce8f
Compare
a4cce8f
to
4fd0121
Compare
3. improve troubleshooting | ||
4. lay the groundwork for collecting agent->resource latency measurements that can be used to make routing decisions based on latency | ||
|
||
Related issues: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
### Health status | ||
|
||
Database target health status will be stored in the DB agent's ephemeral `db_server` heartbeat as the `spec.target_health` field. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be stored in status.target_health instead of spec?
Health checks should be opt-in to avoid issues for existing customers who upgrade. | ||
However, our docs configuration references should have health checks enabled to encourage usage. | ||
|
||
Users can change the default health check settings cluster-wide in `cluster_networking_config`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These settings will not persist in Cloud until #18829 is addressed.
Rendered