-
|
Hey! I have two quick questions to the community. We use a cluster of three machines, and to avoid downtime and do a smooth upgrade, we are thinking to upgrade machine by machine. Our questions are, if we run a cluster made by a mix of CouchDB v2 and CouchDB v3 machines:
I tested on a (really small) test cluster and I read the changelog, all looks good, but before doing it in production I'd like to have feedback from you guys if you have to share. PS: For example I'm aware that compaction could be an issue following #2941 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
rolling upgrades like you describe are supported (modulo the bug you mentioned). We recommend to do those upgrades one after the other, so you don’t run in mixed mode too long. To make sure you don’t run into the bug, you could disable the replication scheduler and delete all .compact files, then do the upgrade (which enables the new replication schedule, so you don’t have to re-enable it). — be sure to adjust your — |
Beta Was this translation helpful? Give feedback.
rolling upgrades like you describe are supported (modulo the bug you mentioned). We recommend to do those upgrades one after the other, so you don’t run in mixed mode too long. To make sure you don’t run into the bug, you could disable the replication scheduler and delete all .compact files, then do the upgrade (which enables the new replication schedule, so you don’t have to re-enable it). — be sure to adjust your
local.inias needed based on our release notes.—
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/