a month ago
I have used a standard typesense image to setup a document library for my app. Followed these steps
1) setup typesense instance (1 replica)
2) loaded it up with document data using the railway url
https://typesense-production-xxx.up.railway.app3) increased typesense to 2 replicas (this triggered a 'this may take some time as we replicate data' message....)
4) I should have checked that both instances yield the same search results but I didn't
My question is, what approach can I take to deploying changes to my search index now that I am in production? I intend to do this weekly. Here is a stab at it....
## Approach 1
1) decrease typesense replicas to 1
2) drop and re-create my document indexes using the railway.app url of the single instance
3) increase replicas to N (say 2)
I think this will work but it clearly produces an outage period.
## Approach 2?
1) for each replica
2) tag the replica as 'offline' or similar.. so it keeps running but isn't available through the public URL of the search function (https://search.myapp.com)... does this exist?
3) drop and re-create my document indexes on the offline replica
This would ensure no outage as the online replicas are still serving customers.
Is there another way to do it? are any of these approaches viable?
Pinned Solution
a month ago
Railway replicas sit behind a single load balanced URL, so any Typesense request can land on any replica. But railway also doesn’t allow Volumes with replicas, so for a stateful service like Typesense that can mean each replica ends up with different local index/data.
Because of that, railway doesn’t really provide a doc supported way to “take one replica offline / drain traffic” while you rebuild it behind the same URL. Instead, for weekly index updates, the safer approach is on the Typesense side: create a new versioned collection (docs_YYYY_MM_DD), import everything into it, then flip a collection alias to point to the new collection ... instant cutover and easy rollback.
So in practice: run Typesense as 1 replica + a Volume for persistence, and use aliases for near-zero downtime reindexing.
4 Replies
a month ago
Railway “replicas” are not the same thing as a real Typesense cluster. If you scaled from 1 to 2 replicas without configuring Typesense clustering (peering addresses, nodes, etc.), you just have two independent nodes behind a load balancer.
Check this page for properly doing a HA type sense setup https://typesense.org/docs/guide/high-availability.html
a month ago
Railway replicas sit behind a single load balanced URL, so any Typesense request can land on any replica. But railway also doesn’t allow Volumes with replicas, so for a stateful service like Typesense that can mean each replica ends up with different local index/data.
Because of that, railway doesn’t really provide a doc supported way to “take one replica offline / drain traffic” while you rebuild it behind the same URL. Instead, for weekly index updates, the safer approach is on the Typesense side: create a new versioned collection (docs_YYYY_MM_DD), import everything into it, then flip a collection alias to point to the new collection ... instant cutover and easy rollback.
So in practice: run Typesense as 1 replica + a Volume for persistence, and use aliases for near-zero downtime reindexing.
lu4p
Railway “replicas” are not the same thing as a real Typesense cluster. If you scaled from 1 to 2 replicas without configuring Typesense clustering (peering addresses, nodes, etc.), you just have two independent nodes behind a load balancer.Check this page for properly doing a HA type sense setup https://typesense.org/docs/guide/high-availability.html
a month ago
thanks for the link, looks very thorough but for my use case I think 2 identical replicas might be easier.
dharmateja
Railway replicas sit behind a single load balanced URL, so any Typesense request can land on any replica. But railway also doesn’t allow Volumes with replicas, so for a stateful service like Typesense that can mean each replica ends up with different local index/data.Because of that, railway doesn’t really provide a doc supported way to “take one replica offline / drain traffic” while you rebuild it behind the same URL. Instead, for weekly index updates, the safer approach is on the Typesense side: create a new versioned collection (docs_YYYY_MM_DD), import everything into it, then flip a collection alias to point to the new collection ... instant cutover and easy rollback.So in practice: run Typesense as 1 replica + a Volume for persistence, and use aliases for near-zero downtime reindexing.
a month ago
thanks, I'll check out collection aliases.
Status changed to Solved brody • 26 days ago