[falcolas]

Persistant volumes rely on NFS (or a flavor thereof), which is not great for database performance.

But that's a moot point anyways, since Vitess doesn't use persistent volumes - it reloads the individual DBs from backups and binlogs when a pod is moved or restarted.

[snuxoll]

> Persistant volumes rely on NFS (or a flavor thereof), which is not great for database performance.

NFS is an option, but it’s not the only option. If you need locally attached storage you can use local PV’s which went GA in Kubernetes 1.14, or any of the plethora of volume plugins that exist for various network storage solutions.

[falcolas]

Network storage, NFS or other, is never optimal for DB storage. It can and is used, but it’s never going to be as good as local storage.

I had forgotten about local storage; it’s not something we can use in our environment.

It’s a moot point, in either case. Vitess doesn’t rely on persistent storage, it relies on replicas and backups.

[dilyevsky]

Are you saying that iscsi is a “flavor of nfs”? What makes it not suitable for good db performance?

[falcolas]

I sincerely beg your forgiveness for forgetting about a feature that’s only about a year old, and a feature we can’t take advantage of in our own kubernetes environment, or with the Vitess cluster.

Forest, trees.

[roman_sf]

couldn't they shovel it into dynamodb?

[falcolas]

Theoretically, sure. But Vitess is - as Kubernetes is - provider agnostic.

But if you’re talking about the DB, sure to that too. But, not my decision.

[roman_sf]

Yeah, I've seen these resume-driven, anti-vendor-locking, everything-is-a-nail-for-kubernetes-hummer decisions :)