hi CB Team
I was trying to make POD up and running with below VolumeClaim definition in Yaml file for Couchbase provided Helm Chart .
As per what I saw is POD up and running fine but the PVC definition has been modified to ‘ReadWriteOnce’ and it didn’t take ‘ReadWriteMany’ . So something is overriding the yaml that is being passed and might be Operator is doing that . So does that mean Couchbase by definition will not allow ReadWriteMany ?
Not sure if that make sense of having cluster pods will read and write on same shared address space in the storage .
Any insights ?
The underlying storage class doesn’t support ReadWriteMany so it’ll be defaulting to that. As a rule of thumb never use ReadWriteMany as that allows multiple pods to access the same storage, at which point you start to run into split brain problems potentially destroying your data.
Understand …thats what I think … so Couchbase StorageClass not supporting this and I guess Operator is ignoring that correct ? Even I make that in YAML POD is not allowing that so … so this not something done by K8s PVC and Storage .
@simon.murray / @tommie - Does Couchbase 6.5 allow Couchbase Pure-File ? I see the deployed PVC working with Pure-File so need to know what are the scenarios to use Pure File vs Pure Block ?
If you are discussing the relative merits of network file vs block storage…
Block is going to be much faster as it’s just reading and writing 512B blocks (perhaps even 4kB) across the network. When you use file then there are whole bunch of other POSIX semantics that need to be thrown across the network and deprive the workload of bandwidth. For databases always use block!
thanks . Sure we will use block as you have suggested . However Helm Chart doesn’t prohibit us to specify pure-file as PVC and cluster Instance starts up and running and working . so I guess undocumented option ? even not recommended
The document here says : "Network file systems such as CIFS and NFS are not supported " so not sure why Pure-file works though .
Even when you are using block, you are using a file system, it just happens to do that locally on the node, not the filer, which is why it’s faster. As a result, everything is a file system and it should just work regardless of your storage layer. So “unsupported” in this case means it’ll probably work, but we don’t recommend it because the performance is rubbish and it’s more critically unreliable, so your database will stop working!
It’s actually not in our interest to allow-list certain storage technologies, because someone will always need a different one which will take time to do and release. It’s best, in my experience, to be permissive.
got it . thanks @simon.murray