Re: Database recommendations?

Philip Nelson
Thu, 22 Feb 2007 23:51:27 -0000

Paul,

Been watching this thread with interest, being a database person myself.

Asking for a database recommendation is a pretty dangerous thing to do : DBMS
debates can get just about as heated as those over preferred editor or IDE.

In many ways, the choice of DBMS comes down to two things -

1) Experience (folks choose what they know and are comfortable with)
2) Money (how much you are prepared to spend for the product and support)

I am not a MySQL person myself (my preferred DBMS is IBM''s DB2, and for
that
my preferred operating platform is Linux).   I have used it on occasion, just
as I have been exposed to Oracle, MS SQL Server, Sybase, Informix and IMS in
my years in the field.

My recommendation to you is that if you are generally comfortable with MySQL
then that would be where you should stay.   The obvious advice would be to
raise a problem report with MySQL support.   I would not advise anyone who is
running a 24x7 database which is critical to the life of their business to
run without some sort of support contract.   I''m sure that MySQL
support
would help diagnose your problem.

If you do want to consider a change, then you have the opportunity to use
almost all of the databases currently available, albeit unsupported, for free
these days.    That''s true for DB2 (Express-C), Oracle (Express
Edition) and
SQL Server (Express Edition).   But be aware that there all of these free
editions have limitations on their use, some more restrictive than others.
The basic details of these are -

DB2 Express-C : server can have maximum of 2 processors (these can be
multi-core however) and 4 gig of RAM.   No limit on database size

Oracle Express : server can only have 1 processor (again multi-core) and 1 gig
of RAM.  Database is limited to 4 gig in size.  Only one database allowed per
server.   Also no 64-bit support (e.g. AMD64 or EM64T).

SQL Server Express : will only use one CPU on a server.   1 gig of RAM only.
4 gig maximum database size.   And, of course, only available on Windows

I think you will agree the DB2 Express-C is much less restricted than the
others.    I can thoroughly recommend it as an excellent platform for 24x7
operations.   It runs beautifully on Linux, and especially on an x64-64
(AMD64 or Intel Xeon with EM64T) platform.

I''m giving a presentation in May at IDUG (http://www.idug.org) on using
DB2
with Ruby on Rails.   It is nearly finished (the final version is due in less
than a fortnight) and if any wants to help me review it ;-) then drop me an
email.   It goes through in some detail using the ibm_db2 adaptor from IBM
Alphaworks.    It doesn''t show you how to install DB2, since my
audience will
know this, but I can help there if you want : given a Linux box, an SSH
connection and a root password my record for going from tarball to working
DB2 system, including sample database, is 12 minutes.

Anyway, as I said before : stay with what you know if you can resolve the
issue.   If you want to look elsewhere you could do a lot worse than DB2 !!!

HTH

Phil

On Thursday 22 February 2007 21:13, Paul Butcher wrote:
> Ilan Berci wrote:
> > I think your real problem is trying to diagnose why your slave is
> > crashing before you assume that you are running up against the upper
> > limits of MySQL replication.
>
> I''d certainly welcome advice on how to perform this diagnosis.
Part of
> the problem that we have is that MySQL provides us with almost no help
> whatsoever in diagnosing the problem.
>
> We know what was the last statement which went through before the crash,
> but it''s "just a query". As far as we can tell, the
problem is that the
> master and the slave got "out of whack" at some point in the past
(and
> we have no means to tell when this point was). The point of failure is
> some stage after that when an otherwise entirely innocuous query runs.
>
> Diagnosing the problem is also not helped by the fact that it has only
> happened twice in 14 months! Most of the time everything runs just fine.
> And we''ve not found a way to reproduce it (we do have automated
stress
> tests, but they don''t seem to do the trick).
>
> We''re thinking of moving database at least in part because, quite
apart
> from this problem, we know that we''re going to hit a wall with
MySQL
> replication anyway. The slave exists to provide a failover if the master
> dies. Let''s imagine that happens 6 months down the line. We can
failover
> to the slave (assuming that the replication is working at the time!),
> but at some point we''ll need to recreate a replication
relationship from
> the new master to a new slave. MySQL replication requires us to take the
> master down while we create the slave. With a database which is an order
> of magnitude larger than we have right now, which is the size we expect
> it to be in 6 months, this is going to mean being down for an hour -
> which is completely unacceptable for our app.
>
> So we''ve been thinking of moving anyway - the current problems
we''ve
> been experiencing have just accelerated our thinking.
>
> >  What are the details of your master/slave
> > setup?, (a)synchronous?, distributed query load to slave?,
> > auto-generated keys? load?.
>
> Most of our tables are InnoDB, but we do have a couple of MyISAM tables
> (because we use MySQL fulltext indices on those tables). The slave runs
> read-only and replicates from the binary log on the master (which is a
> very standard MySQL replication setup as far as I can tell). Just about
> all tables are "standard" RoR style tables, so they have
autoincrement
> "id" columns, but are pretty much "plain vanilla" apart
from that. No
> stored procedures, no transactions (other than the implicit transactions
> that InnoDB creates as part of its normal operation). We do use foreign
> key constraints though (although I can''t see why that should cause
any
> problems).
>
> > It should be fairly straight forward to look at the db logs on the
slave
> > to see the last statement that went through before the crash..   I
also
> > guess it''s obvious to assume that your slave is a dedicated
db server..
> > right?   Is the crash dependant upon load?
>
> Yes, the slave is a dedicated server. It''s hard to say whether the
crash
> is dependent on load - as it''s only happened twice it''s
hard to see a
> pattern!
>
> Thanks for any suggestions you can offer!
>
> paul.butcher->msgCount++

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com