graphprotocol / graphprotocol/graph-node
[Feature] Graceful shutdown
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Rust
- Sterne
- 3.2k
- Forks
- 1.1k
- Ø Merge
- 4 T. 1 Std.
- Gemergte PRs (30 T.)
- 1
Beschreibung
Description
I'm using graph-node in kubernetes with a sql proxy to connect to postgresql.
When I do a replace of the graph-node, kubernetes sends a SIGTERM and will wait 30s before forcing a shutdown.
I'm waiting 30s in the SQL proxy to let the graph-node to finish its queries.
But the graph-node does not stop, It just sends errors because the database goes away and waits for kubernetes to force the kill of the pod.
A nice feature would be to permit a graceful shutdown of the graph-node.
It should stop indexing on SIGTERM, finish its sql queries and disconnect to the database.
More, it can prevent some unexpected issues in postgresql database like bad block caching.
An indexer node or query has actually the same behaviour.
Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
No response
Some information to help us out
- Tick this box if you plan on implementing this feature yourself.
- I have searched the issue tracker to make sure this issue is not a duplicate.
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne damit, nachzuverfolgen, wie graph-node SIGTERM verarbeitet und wie seine Indexierungs- und Abfrageprozesse beendet werden. Überprüfe das Herunterfahrverhalten mit Kubernetes und dem SQL proxy. Stelle anschließend sicher, dass die Indexierung beendet wird, laufende SQL-Abfragen abgeschlossen werden und die PostgreSQL-Verbindung getrennt wird, bevor das 30-Sekunden-Terminierungsfenster abläuft.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- kubernetes, postgresql, rust
- Bereich
- backend, databases, infrastructure
- Issue-Typ
- Feature
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100