Multi-host failover causes user-facing connection delays after HostRecheckSeconds

Ouverte
  • Quelque chose ne va pas ?
#6,483 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 6 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
28/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
csharp, postgresql
Domaine
backend, databases

Piste de recherche

Start by tracing Npgsql's multi-host failover and HostRecheckSeconds behavior in the connection path; the issue does not name a file or test. Compare the current retry behavior with the proposed background probing strategy, including how it should interact with connection pooling and target_session_attrs=primary. Done would require a decided behavior or option that avoids delaying requests when a healthy host is available, with tests covering the failure scenario.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

We are currently using Npgsql with a multi-host configuration for PostgreSQL failover (no load balancing). While testing failure scenarios we observed behavior which can introduce significant latency for user requests.

It appears that the current host recheck mechanism may cause user requests to block on connection attempts to a previously failed host, even though a healthy host is available.

Configuration

Example connection string:

Host=server1,server2;
load_balance_hosts=false;
Host Recheck Seconds=5;
Timeout=2;
target_session_attrs=primary
Maximum Pool Size=5;

Scenario assumptions:

  • server1 = primary host
  • server2 = failover host
  • no load balancing
  • application uses the default connection pooling
Observed behavior
  1. Application initially connects to server1.
  2. server1 becomes unavailable.
  3. A connection attempt fails and server1 is marked as down.
  4. The driver starts using server2 successfully.
  5. After HostRecheckSeconds (e.g. 5 seconds), the driver tries server1 again.

If server1 is still unavailable, multiple concurrent requests attempt to connect to it again.

Because the connection attempt waits for the configured Timeout, these requests block for the full timeout duration before falling back to server2.

Example timeline:

Hosts: server1, server2
HostRecheckSeconds = 5
Timeout = 2

If server1 is still down:

  • every 5 seconds the driver retries server1
  • concurrent connection attempts wait up to 2 seconds
  • only afterwards do they fall back to server2

This results in user requests experiencing ~2 seconds of latency, even though server2 is fully healthy and could respond immediately.

With higher concurrency (e.g. Maximum Pool Size), many requests may be delayed simultaneously.

Expected behavior

From an application perspective, a preferable strategy would be:

  • once a host is marked as down, continue using the healthy host
  • periodically probe the failed host in the background
  • avoid blocking user requests on retry attempts to the failed host

This would prevent unnecessary latency spikes when one host remains unavailable.

Question

Is the current behavior intentional?

If so, is there a recommended way to avoid user-facing delays when using multi-host failover without load balancing?

Alternatively, would it make sense to introduce an option to probe failed hosts in the background rather than during user connection attempts?

Environment
  • Npgsql version: 8.0.6
  • .NET SDK-version: 8.0.418
Langage dominant
C#
Étoiles
3.7k
Forks
890
Merge moyen
4 j 11 h
PR mergées (30 j)
19

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de npgsql/npgsql

Toutes les issues de npgsql/npgsql

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.