Skip to content
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

How to Set Up High Availability (HA) and Upgrade Warpgate with PostgreSQL as the Database #1087

Open
vjmax opened this issue Oct 16, 2024 · 1 comment

Comments

@vjmax
Copy link

vjmax commented Oct 16, 2024

Hi,

I’m currently using Warpgate with PostgreSQL as my backend database, and I’m looking for guidance on two things:

High Availability (HA):
What’s the best approach to set up HA for Warpgate? I am using PostgreSQL for the database and want to ensure that Warpgate is highly available with multiple instances, preferably behind a load balancer. Are there any best practices or tools (e.g., HAProxy, Nginx) to achieve this? Additionally, how should the Warpgate configuration and session data be managed across multiple instances?

Upgrading Warpgate:
Could you provide steps or best practices for upgrading from one version of Warpgate to another while using PostgreSQL? Specifically, I want to know how to handle database migrations, any potential schema changes, and the general process to ensure a smooth upgrade with minimal downtime.

Thanks in advance for your help! Any advice or documentation would be greatly appreciated.

@Eugeny
Copy link
Member

Eugeny commented Oct 16, 2024

Multiple Warpgate instances can work with the same database at the same time without any need for synchronization, however if you put a load balancer in front of them, the load balancer has to provide session stickiness (TCP connection based for SSH/MySQL/Postgres and cookie based for HTTP) as session storage is local to each service.

As for database migrations, currently there is no provision for running mixed versions against the same database. When Warpgate service starts, it automatically applies any new database migrations that haven't been applied yet - so upgrading a cluster requires downtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants