Search results

aha. I suppose the ultimate issue is rsync cant copy deleted files, even if we can get at the content via /proc/*/fd - no way to drop it in the right place in the filesystem for the migrated container to find without some kinda hacky support in the OpenVZ kernel. Actually Im quite suprised that...

few comments down in that thread I posted on the bug: https://bugzilla.openvz.org/show_bug.cgi?id=2242#c33 more specifically: https://bugzilla.openvz.org/attachment.cgi?id=1886&action=diff

maria has even more links to deleted files in /tmp for some reason (not that it matters, any more than zero is an issue). it's still better than mysql :) however, im not always aware and can't vette every piece of software my customers will run, so migratability could be an issue without this...

in an ideal world of cooperative under-one-person/design's control yes, that'd be great, but I support multiple different customers with various versions of mysql and debian etc etc. It's a big mixed bag. Any proper virtualization/containerization environment can support these disparate servers...

some technical elements brought here from http://forum.proxmox.com/threads/11983-OpenVZ-Ploop-support bug is caused by mysql keeping FH's open on unlinked files: https://bugzilla.openvz.org/show_bug.cgi?id=2242 a patch is out for that. However, I suspect think this will not work with rsync...

I dont think that would work - cant just suspend mysql, you need to completely shut it down. The reason is because this is the actual bug: https://bugzilla.openvz.org/show_bug.cgi?id=2242#c26 summary: mysql keeps filehandles open on unlinked (deleted) files. [facepalm] There's a patch to the...

Right now im under the belief that use of ploop for containers would solve the mysql migration issue by providing an actual filesystem image where inodes map to the same files on any host once live-migrated (vs living on the very different filesystems of the hosts). If im wrong, then we can...