From: Les M. <les...@gm...> - 2012-08-07 16:19:43
|
On Tue, Aug 7, 2012 at 10:42 AM, Tyler J. Wagner <ty...@to...> wrote: >> > Except then you have the problem of when that DB is written out, and how to > dump it for backup or moving. As you later said, you get easy redundancy > with MySQL. Easy is probably the wrong word there. Possible, maybe. And, unless you put the content in the db, you still have to deal with consistency with the filesystem. >> Another thing to consider is the difficulty of moving your >> installation from one machine to another (probably with a different or >> upgraded OS, possibly with a different CPU type) without losing >> history, Or making duplicate copies for offsite storage. Having to >> deal with a separate daemon and a separately-changing data format adds >> complications for not-much benefit unless it also lets you scale up or >> gives you redundancy. > > That's not a problem for anyone who has ever moved a website. You move > files independently from the database. For a simple move or backup, it's > easy to script mysqldump+rsync+mysql. Umm, no. That means your web site is down for the duration or the backup is inconsistent. Web sites that scale would already be running a distributed DB. > Apropos (or perhaps ironic) to this discussion, all of my servers running > MySQL run webmin, and so have MySQL backups made daily. This gets grabbed > by BackupPC daily, so I have a reasonably stable DB state in BackupPC. You can do that without webmin (just ssh it in the pre-user command), and I have some like that too. It works, but it's not a great fit for backuppc since even small changes in the file defeat pooling. -- Les Mikesel les...@gm... |