5 days ago
This is what i see on the deploy logs. Nothing happens....
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/d56a1ee2-2edd-45d3-a4a8-cb73d68ffb1e/vol_xeqd8japfyi55u3q
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/d56a1ee2-2edd-45d3-a4a8-cb73d68ffb1e/vol_xeqd8japfyi55u3q
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/d56a1ee2-2edd-45d3-a4a8-cb73d68ffb1e/vol_xeqd8japfyi55u3q
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/d56a1ee2-2edd-45d3-a4a8-cb73d68ffb1e/vol_xeqd8japfyi55u3q
what could be the issue ? And why the heck did my running pod got destroyed while the other one was not up....
This are the logs from the successful deployment (that was running):
shutdown complete
Stopping Container
Stopping Container
Should this not shutdown the service when we now the other service will run ?
How can we improve this that something like that not happens. Now i have a downtime.
5 Replies
5 days ago
This may happen when your service has a volume, and since two deployments can not be mounted to the same volume at the same time, we must stop the previous deployment before starting the new deployment. This has always been the logic since we first introduced support for volumes.
Users have worked around this by offloading storage to a separate service such as MinIO so that their main application will not need a volume and thus is not subject to the mandatory downtime.
Status changed to Awaiting User Response Railway • 5 days ago
Railway
This may happen when your service has a volume, and since two deployments can not be mounted to the same volume at the same time, we must stop the previous deployment before starting the new deployment. This has always been the logic since we first introduced support for volumes. Users have worked around this by offloading storage to a separate service such as MinIO so that their main application will not need a volume and thus is not subject to the mandatory downtime.
5 days ago
How can i fix the current problem now since it tries to mount the volume.
Status changed to Awaiting Railway Response Railway • 5 days ago
5 days ago
Maybe i did not understand clearly the problem and some of you guys can help me out here. I use postgres and postgres has a volume attached. While other apps are not using any volume why did this problem exists ? I understand what the bot was saying but it should not be the case here right ?
Status changed to Awaiting Railway Response Railway • 5 days ago
5 days ago
Your "bookly" service also has a volume attached (mounted at /app/data), so the volume-swap downtime applies to it as well, not just Postgres. If you don't need persistent disk on the bookly service, removing that volume would let its deployments roll over without downtime.
Status changed to Awaiting User Response Railway • 5 days ago
sam-a
Your "bookly" service also has a volume attached (mounted at `/app/data`), so the volume-swap downtime applies to it as well, not just Postgres. If you don't need persistent disk on the bookly service, removing that volume would let its deployments roll over without downtime.
4 days ago
oh thanks.... I really thought i deleted it. Because that was the reason why i switched to s3 and only postgres. I wanted to avoid having persisted volume on ther service itself. Thanks !!!
Status changed to Awaiting Railway Response Railway • 4 days ago
Status changed to Solved cuberinooo • 4 days ago