And still, nobody answered the man's actual question: can a Linux mysqld
read mac datafiles ?
I'd say "make a copy and try it". As long as you always keep a copy of the
original files, you're not risking anything. You might run into things
varying from incompatible MySQL versions to different endianness on your
files - I don't know. Try and you'll see.
Worst case scenario, get an identical mac with an identical mysql and copy
the files to that.
On Fri, Sep 10, 2010 at 10:57 AM, Joerg Bruehe <joerg.bruehe@stripped>wrote:
> Hi George, everybody!
> George Larson wrote:
> > We do nightly backups at work just by taring the mysql directory. In
> > my environment, that is /var/lib/mysql.
> > Like this:
> > service mysql stop
> > cd /var/lib/mysql
> > rm -rf *
> For your own benefit, I hope you don't do that on the machine on which
> the (primary) DB server is installed.
> > tar zxvf file.tar
> > rm -rf ib_logfile*
> > chown -R mysql.mysql
> > service mysql start
> The above procedure may work on a backup machine, to which you transfer
> a "file.tar" which contains a database snapshot. So it is a recovery/
> restore procedure, not the save/backup part.
> Assuming the data are below /var/lib/mysql on the broken machine, and
> that disk is mounted as /mnt, this would be like:
> cd /mnt/var/lib/mysql
> tar czvf /tmp/file.tar .
> Take care not to damage that disk, or to use it for any other purpose,
> until you have verified that your new database server could successfully
> read and use all those data (do thorough checks!), and taken a full new
> backup from it.
> In general, I do not recommend to use file backups for a database, but
> rather to use the database means (backup, dump, ...). However, after
> your database machine broke, this isn't so easily possible.
> > Something similar might work for you. Somebody with more MySQL
> > expertise than me can probably help you customize the process to your
> > environment.
> To the original poster:
> I know it sounds very hard and seems to ignore your trouble, but still:
> A typical reply in DB support is
> "If you have no backup, your data obviously are not important."
> Everything can fail, both hard- and software: if your data are valuable,
> you need a backup which is separated from the machine your data are on.
> "Separated" might be an external disk that gets switched off, a tape
> that is removed from its drive, another machine, just anything that
> won't suffer even if your database server breaks terribly.
> (To prevent questions: Mirrored disks or RAID systems are no backup, as
> they are not separated.)
> If backup is to external disk, my personal policy is to have at least
> two of these, used in alternation: If total disaster strikes while one
> is mounted and being written to, and that disaster affects all mounted
> disks (data and current backup), I still have the previous backup.
> Given current disk prices, one sleepless night will cost you more than
> the second disk.
> How often you do this backup is a decision you have to make yourself,
> based on your update frequency and the possibility/cost to repeat the
> changes that occurred since the last backup.
> Joerg Bruehe, MySQL Build Team, joerg.bruehe@stripped
> ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
> Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
> Amtsgericht Muenchen: HRA 95603
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel