Huh? Not know how to backup a MySQL database? *sigh*

Every night, I do a backup of our MySQL database server that's holding all of our mail and various other things (20GB+).

I set the isolation level to READ_REPEATABLE and use mysqldump | bzip2 to get the result. I've tested the restore and it's fine! A uni project I was
working on this year that stored images and other binary stuff in BLOB fields was successfully backed up in a similar fashion. This all applies to InnoDB tables. I've
heard cases of needing to use READ_COMMITED as the isolation level in some cases, as one can run into issues with memory consumption / table space problems if your
traffic is high.


To backup those funky sleek MyISAM tables, you could just issue a LOCK TABLE statement or two (LOCK DATABASE?), do a FLUSH and copy the files. If I recall correctly,
(and I'm sure sirs DuBois and Zawodny will find out where I live and deal with me if I don't :-) ), this might be how the mysqlhotcopy script works.


Regarding Interbase/Firebird - you're talking about a database with a very long and detailed history. The fact there is one file per database doesn't mean much - InnoDB has one file per server should you want to configure it that way and no stable release allows you to break up your databases or tables into files in any fashion other than what InnoDB itself decides to do with the ibdata* files you allow it to have. Interbase is still one of the most popular embedded databases in the world! Even more popular than (ick) FileMaker Pro and (vomit) FoxPro! Just looking at the number of third party tools out there
that support development using it is a pretty decent vote of it's industry acceptance.


I'm curious as to why you're not comfortable with MySQL. It truly features the best of all worlds when it comes to performance options and I've found the community support (Read: The MySQL mailing list)
to be far more valuable than any course I've looked at or taken. I'd be very interested in hearing more from you, as I'm betting a few other readers on both lists would.


Best regards,

Chris



Sven Köhler wrote:

So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are
possible candidates.
Does anyone know why we should or should not use any of these? Does anyone
know of other possibilities?


I was very disappointed by Interbase/Firebird. It seemed to me like a MS-Access: a database-engine that works on regular files
OK, there is a network-server component, but it really has nothing to do with an enterprise-DB.


It is a mystery to me how the PostGreSQL work. I cannot recomm to use any feature discovered in PostGreSQL since some of the more uncommon feature are broken.

I have only recently started these evaluations. BTW, my own background is
from the Oracle DBA world.


Well, the DBMS comparable to Oracle is neither MySQL nor Firebird.
It's MaxDB.

MySQL is certainly popular and seems to have very good performance, but I am
concerned that the lack of Triggers, Stored Procedures, User-Defined
Functions, and Views (to a lesser degree ) will be a disadvantage.


And foreign-keys are a feature you shouldn't miss to.
MySQL does offer them by patching it with InnoDB.

MaxDB "appears" to be more feature-rich and possibly more
industrial-strength. How does its performance and stability compare to the
others?


I'm using MaxDB and it's running 24/7 without problem on a web-server with a Java-WebApp. Before using MaxDB you should first look at the limits that MaxDB has. For example a row in a table may only store data up to 8KB. BLOP and CLOP columns don't count, but even for varchar-columns 8KB is a bit few. MaxDB has Unicode-support (UCS2) which is extremely important for Java-Clients. If using Unicode, 8KB means 4000chars. CLOB and BLOB-columns in MaxDB aren't comparable. You cannot use "like" or <,>,= on them. MaxDB even doesn't have a FullText-Search, but to me it's not that important since i can replace them with Java-based search-engines like Lucene. MaxDB has a mechanism to backup your database without breaking anything. MaxDB supports Server-side prepared statement. The JDBC-driver is of good quality. Bugs are fixed relativly fast.

My favourite DBMS could be PostGreSQL if i only knew which features are stable and which are not. A strange thing is, that the PostGreSQL-people decided to use UTF-8 for their unicode-support. In my eyes that makes it different to calculate string-lengthts and comparisons. But their argument is, that UTF-8 usually causes less disk-io. But does varchar(400) now mean 400bytes or 400chars? i don't know.
I didn't take a close look at PostGreSQL yet, so all features that i mentioned about MaxDB might apply to PostGreSQL too.


On both, MaxDB and PostGreSQL, you need to perform regular tasks. You must update the optimizer statistics for MaxDB, and run VACUUM for PostGreSQL.

MySQL, well, i wouldn't know how to backup it, except by using a dump. How can i dump a table with binary data? I don't wanna know. A dump is not a backup, it's crap. Than there's the lack of Unicode-support, Foreign Keys, prepared statements (emulated by client-lib if available as far as i know), ... That all doens't make me feel comfortable about MySQL.





--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]



Reply via email to