mirror of
https://github.com/neondatabase/neon.git
synced 2026-05-20 06:30:43 +00:00
0c105ef352
This PR stacks on https://github.com/neondatabase/neon/pull/6814 Observability: - Because we only persist a subset of our state, and our external API is pretty high level, it can be hard to get at the detail of what's going on internally (e.g. the IntentState of a shard). - Add debug endpoints for getting a full dump of all TenantState and SchedulerNode objects - Enrich the /control/v1/node listing endpoint to include full in-memory detail of `Node` rather than just the `NodePersistence` subset Consistency checks: - The storage controller maintains separate in-memory and on-disk states, by design. To catch subtle bugs, it is useful to occasionally cross-check these. - The Scheduler maintains reference counts for shard->node relationships, which could drift if there was a bug in IntentState: exhausively cross check them in tests.
58 lines
1.9 KiB
Rust
58 lines
1.9 KiB
Rust
use control_plane::attachment_service::{NodeAvailability, NodeSchedulingPolicy};
|
|
use serde::Serialize;
|
|
use utils::id::NodeId;
|
|
|
|
use crate::persistence::NodePersistence;
|
|
|
|
/// Represents the in-memory description of a Node.
|
|
///
|
|
/// Scheduling statistics are maintened separately in [`crate::scheduler`].
|
|
///
|
|
/// The persistent subset of the Node is defined in [`crate::persistence::NodePersistence`]: the
|
|
/// implementation of serialization on this type is only for debug dumps.
|
|
#[derive(Clone, Serialize, Eq, PartialEq)]
|
|
pub(crate) struct Node {
|
|
pub(crate) id: NodeId,
|
|
|
|
pub(crate) availability: NodeAvailability,
|
|
pub(crate) scheduling: NodeSchedulingPolicy,
|
|
|
|
pub(crate) listen_http_addr: String,
|
|
pub(crate) listen_http_port: u16,
|
|
|
|
pub(crate) listen_pg_addr: String,
|
|
pub(crate) listen_pg_port: u16,
|
|
}
|
|
|
|
impl Node {
|
|
pub(crate) fn base_url(&self) -> String {
|
|
format!("http://{}:{}", self.listen_http_addr, self.listen_http_port)
|
|
}
|
|
|
|
/// Is this node elegible to have work scheduled onto it?
|
|
pub(crate) fn may_schedule(&self) -> bool {
|
|
match self.availability {
|
|
NodeAvailability::Active => {}
|
|
NodeAvailability::Offline => return false,
|
|
}
|
|
|
|
match self.scheduling {
|
|
NodeSchedulingPolicy::Active => true,
|
|
NodeSchedulingPolicy::Draining => false,
|
|
NodeSchedulingPolicy::Filling => true,
|
|
NodeSchedulingPolicy::Pause => false,
|
|
}
|
|
}
|
|
|
|
pub(crate) fn to_persistent(&self) -> NodePersistence {
|
|
NodePersistence {
|
|
node_id: self.id.0 as i64,
|
|
scheduling_policy: self.scheduling.into(),
|
|
listen_http_addr: self.listen_http_addr.clone(),
|
|
listen_http_port: self.listen_http_port as i32,
|
|
listen_pg_addr: self.listen_pg_addr.clone(),
|
|
listen_pg_port: self.listen_pg_port as i32,
|
|
}
|
|
}
|
|
}
|