Replication

[Pailloncy Jean-Gérard]

Hi,

I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
http://www.mysql.com/products/cluster/
We need to see when stable version would be released.....

I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.

Any comments ? (no flame, please)

Cordialement,
Jean-Gérard Pailloncy

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Andrew Sullivan]

On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:

Hi,

I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).

It looks like it's based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don't tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn't support the other table types. I don't want to
contemplate the horrible mess you'd have to clean up if you had a
transaction crossing three table types and get a hardware failure.

I'm afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.
I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.

Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)

A

--
Andrew Sullivan | aj*@crankycanuc k.ca

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Jan Wieck]

Andrew Sullivan wrote:

On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:

Hi,

I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).

It looks like it's based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don't tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn't support the other table types. I don't want to
contemplate the horrible mess you'd have to clean up if you had a
transaction crossing three table types and get a hardware failure.

I'm afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.

Quoting from the MySQL(tm) FAQ about MySQL(tm) Cluster(tm) avaliable at
http://www.mysql.com/products/cluster/faq.html

<quote>
Q: Does MySQL Cluster work with MyISAM and InnoDB?

A: MySQL Cluster can include the MyISAM and InnoDB storage engines. Of
these, the high-availability data must reside in the MySQL Cluster
storage engine.

The MySQL Cluster DB node stores MySQL Cluster data, the MySQL Server
parses SQL and sends requests to the DB node. The MySQL Server does not
store any data belonging to the MySQL Cluster storage engine.

InnoDB/MyISAM data is still stored in the MySQL server and can be used
in the standard way, but that data is not replicated, so that data is
not visible from any other MySQL server that is connected to the MySQL
Cluster.
</quote>

It is just another table handler made available for the SQL query
engine. Touting loudly and on all available channels that "MySQL Cluster
combines the world's most popular open source database with a
parallel-server" naturally leads to the misinterpretati on that all the
wonderfull new features like foreign keys, MVCC and rollback will now
horizontally scale over multiple, high available nodes. This is not true.

The NDB table type does not have support for foreign keys, constraints,
triggers. It does support transactions, but these transactions are not
the same transactions as the ones of the InnoDB table handler, so a
COMMIT is not atomic across different table types. MySQL likes to point
out that the largest systems like SAP R/3 do not use referential
integrity on the database level. That is true so far, but having worked
for many years as an SAP base consultant I can tell you that the reason
for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.

Also, the NDB table type is based on an in-memory, partitioned storage
engine (that's where the speed comes from) and to get high availablility
one needs at least two times the full database size in RAM (plus some
for the OS and other overhead), and a higher factor to really achieve
the 99.999%. So to serve let's say a 100 GB database, we're talking
about 220-240 GB of RAM. Now that's 8 boxes with 32GB each? And
according to a MySQL consultant I spoke with, the real bottleneck is the
network, so these boxes like to have "better than Gigabit Ethernet" as a
backbone. That are some decent hardware requirements, make sure you have
a forklift on your next shopping list.

So what one gets with NDB on the bottom line is another table type that
is usefull for some special cases. I can imagine for example systems
that read sensor data, which cannot be interrupted. Sensors usually
don't care much about referential integrity, so for the logging system
this is in fact irrelevant, the data has to be stored now and corrected
later. I think it is indeed a big plus for a system, to make that
logging data available inside the same SQL query engine where the more
complicated bits and pieces of the application are implemented in. But
that is all, and that can pretty easy be achieved by doing bulk-loads of
the log data into regular database tables. Unless one really needs the
ability to query and analyse up to the last second of logdata, running
some multiple 100 kilodollar hardware and network equipment just for the
fun of a memory cluster solution is a bit overkill.

As the Oracle VP of product strategy, Ken Jacobs, pointed out: "MySQL is
trying to address certain product shortcomings by acquiring a
third-party technology. This does not mean they now have a product that
is competitive with Oracle—or even other—database products, whether
clustered or not.". Absolutely right Mr. Jacobs, they have done that
before by adding InnoDB, now they added some limited multimaster
replication capabilities. But instead of developing an integrated
solution that includes the InnoDB table handler, where this
functionality would be usefull, they just added a fifth wheel to the cart.

I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.

Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)

Ken Jacobs further said "No one has anything at all like Oracle's Real
Application Clusters". And that is right too. However good PostgreSQL by
now compares on SQL features and standalone DB performance. On
replication we are 2 years or more behind.

Right now we need to get the Slony-I project out the door and let that
settle a bit and maybe get enhanced over one more release. With that as
the base, we will start designing a synchronous multimaster system that
can be jump-started from a running, asynchronous replication setup. All
this "high-availability" babble is IMHO totally pointless as long as
there is no way of (re)creataing a (failed) node from scratch without
taking an outage. And that functionality is listed on the MySQL roadmap
for 5.1 ... so somewhere in 2008? Slony does that for async master-slave
right today.
Jan

--
#============== =============== =============== =============== ===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#============== =============== =============== ====== Ja******@Yahoo. com #
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Jan Wieck]

Andrew Sullivan wrote:

On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:

Hi,

I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).

It looks like it's based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don't tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn't support the other table types. I don't want to
contemplate the horrible mess you'd have to clean up if you had a
transaction crossing three table types and get a hardware failure.

I'm afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.

Quoting from the MySQL(tm) FAQ about MySQL(tm) Cluster(tm) avaliable at
http://www.mysql.com/products/cluster/faq.html

<quote>
Q: Does MySQL Cluster work with MyISAM and InnoDB?

A: MySQL Cluster can include the MyISAM and InnoDB storage engines. Of
these, the high-availability data must reside in the MySQL Cluster
storage engine.

The MySQL Cluster DB node stores MySQL Cluster data, the MySQL Server
parses SQL and sends requests to the DB node. The MySQL Server does not
store any data belonging to the MySQL Cluster storage engine.

InnoDB/MyISAM data is still stored in the MySQL server and can be used
in the standard way, but that data is not replicated, so that data is
not visible from any other MySQL server that is connected to the MySQL
Cluster.
</quote>

It is just another table handler made available for the SQL query
engine. Touting loudly and on all available channels that "MySQL Cluster
combines the world's most popular open source database with a
parallel-server" naturally leads to the misinterpretati on that all the
wonderfull new features like foreign keys, MVCC and rollback will now
horizontally scale over multiple, high available nodes. This is not true.

The NDB table type does not have support for foreign keys, constraints,
triggers. It does support transactions, but these transactions are not
the same transactions as the ones of the InnoDB table handler, so a
COMMIT is not atomic across different table types. MySQL likes to point
out that the largest systems like SAP R/3 do not use referential
integrity on the database level. That is true so far, but having worked
for many years as an SAP base consultant I can tell you that the reason
for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.

Also, the NDB table type is based on an in-memory, partitioned storage
engine (that's where the speed comes from) and to get high availablility
one needs at least two times the full database size in RAM (plus some
for the OS and other overhead), and a higher factor to really achieve
the 99.999%. So to serve let's say a 100 GB database, we're talking
about 220-240 GB of RAM. Now that's 8 boxes with 32GB each? And
according to a MySQL consultant I spoke with, the real bottleneck is the
network, so these boxes like to have "better than Gigabit Ethernet" as a
backbone. That are some decent hardware requirements, make sure you have
a forklift on your next shopping list.

So what one gets with NDB on the bottom line is another table type that
is usefull for some special cases. I can imagine for example systems
that read sensor data, which cannot be interrupted. Sensors usually
don't care much about referential integrity, so for the logging system
this is in fact irrelevant, the data has to be stored now and corrected
later. I think it is indeed a big plus for a system, to make that
logging data available inside the same SQL query engine where the more
complicated bits and pieces of the application are implemented in. But
that is all, and that can pretty easy be achieved by doing bulk-loads of
the log data into regular database tables. Unless one really needs the
ability to query and analyse up to the last second of logdata, running
some multiple 100 kilodollar hardware and network equipment just for the
fun of a memory cluster solution is a bit overkill.

As the Oracle VP of product strategy, Ken Jacobs, pointed out: "MySQL is
trying to address certain product shortcomings by acquiring a
third-party technology. This does not mean they now have a product that
is competitive with Oracle—or even other—database products, whether
clustered or not.". Absolutely right Mr. Jacobs, they have done that
before by adding InnoDB, now they added some limited multimaster
replication capabilities. But instead of developing an integrated
solution that includes the InnoDB table handler, where this
functionality would be usefull, they just added a fifth wheel to the cart.

I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.

Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)

Ken Jacobs further said "No one has anything at all like Oracle's Real
Application Clusters". And that is right too. However good PostgreSQL by
now compares on SQL features and standalone DB performance. On
replication we are 2 years or more behind.

Right now we need to get the Slony-I project out the door and let that
settle a bit and maybe get enhanced over one more release. With that as
the base, we will start designing a synchronous multimaster system that
can be jump-started from a running, asynchronous replication setup. All
this "high-availability" babble is IMHO totally pointless as long as
there is no way of (re)creataing a (failed) node from scratch without
taking an outage. And that functionality is listed on the MySQL roadmap
for 5.1 ... so somewhere in 2008? Slony does that for async master-slave
right today.
Jan

--
#============== =============== =============== =============== ===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#============== =============== =============== ====== Ja******@Yahoo. com #
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Andrew Sullivan]

On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:

for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.

Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things efficiently,
and that means doing the work in the place where it is least likely
to need to be checked again. For most database applications, that's
inside the database. (I'll not now start my rant on the mess caused
by developers who are careless with this principle.)

A

--
Andrew Sullivan | aj*@crankycanuc k.ca
The plural of anecdote is not data.
--Roger Brinner

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Andrew Sullivan]

On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:

for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.

Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things efficiently,
and that means doing the work in the place where it is least likely
to need to be checked again. For most database applications, that's
inside the database. (I'll not now start my rant on the mess caused
by developers who are careless with this principle.)

A

--
Andrew Sullivan | aj*@crankycanuc k.ca
The plural of anecdote is not data.
--Roger Brinner

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Uwe C. Schroeder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 21 April 2004 10:28 am, Andrew Sullivan wrote:

On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:

for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.

Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things efficiently,
and that means doing the work in the place where it is least likely
to need to be checked again. For most database applications, that's
inside the database. (I'll not now start my rant on the mess caused
by developers who are careless with this principle.)

I concur. However the problem SAP had some 18years ago when they invented
their system were massive differences between databases. The scope they had
in mind didn't allow for whole database layers to be redundant just for the
sake of being able to talk to several database engines - ergo they wrote one
layer and omitted using vendor dependant database features.
Nowadays most relevant databases are pretty compatible when it comes to
constraints, so if you stick to the basics you should be fine now.

UC

- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: [phone] San Bruno, CA 94066
Cell: [phone] United States
Fax: [phone]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAhvgKjqG XBvRToM4RAmy1AJ 9q2n44+9KFAp+o2 u3NPqR6DISyGACe PO6V
a6L/yfArAk3m0N6lSQV Dx0k=
=dRNi
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Uwe C. Schroeder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 21 April 2004 10:28 am, Andrew Sullivan wrote:

On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:

for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.

Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things efficiently,
and that means doing the work in the place where it is least likely
to need to be checked again. For most database applications, that's
inside the database. (I'll not now start my rant on the mess caused
by developers who are careless with this principle.)

I concur. However the problem SAP had some 18years ago when they invented
their system were massive differences between databases. The scope they had
in mind didn't allow for whole database layers to be redundant just for the
sake of being able to talk to several database engines - ergo they wrote one
layer and omitted using vendor dependant database features.
Nowadays most relevant databases are pretty compatible when it comes to
constraints, so if you stick to the basics you should be fine now.

UC

- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: [phone] San Bruno, CA 94066
Cell: [phone] United States
Fax: [phone]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAhvgKjqG XBvRToM4RAmy1AJ 9q2n44+9KFAp+o2 u3NPqR6DISyGACe PO6V
a6L/yfArAk3m0N6lSQV Dx0k=
=dRNi
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Christopher Browne]

Martha Stewart called it a Good Thing when aj*@crankycanuc k.ca (Andrew Sullivan) wrote:

On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:

for that is NOT performance. SAP spends that effort multiple times
by implementing their own, custom integrity control and data domain
system in the DB abstraction layer, to gain DB vendor
independence. That abstraction layer is larger than PHP and Apache
together, so this example is IMHO totally irrelevant for the
typical MySQL user.

Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things
efficiently, and that means doing the work in the place where it is
least likely to need to be checked again. For most database
applications, that's inside the database. (I'll not now start my
rant on the mess caused by developers who are careless with this
principle.)

There's a further issue, namely that these "bankrupt" ways were
adopted literally decades ago, and involve the "trillion-dollar"
investments.

Way back when, R/2 was implemented on MVS using IMS, and SAP
implemented their own toolset to manage that, including their own
more-or-less-implicit transaction manager. Thirty years later, they
have ported it to run on systems that didn't exist back then, but it's
still, in essence, a "mainframe" thing, even if you're running it atop
Windows NT and Microsoft's port of Sybase. It persists because
there's 30 years worth of ABAP/4 code customized for a zillion
purposes that SAP can keep on selling.

The problem is not one of carelessness; it is that R/2 was written to
run on databases like IMS, a pre-relational hierarchical system, and
Adabas, which couldn't support having more than 256 tables, once upon
a time... They had to create an ad-hoc variation on CICS, and
starting from scratch would cost trillions.

Even they couldn't afford that. Microsoft has been trying to do some
"reinventio n" of Windows in the new "Longhorn" thing, and despite
having $Billion$ in the bank, it looks like those ambitions are dying
the death of a thousand paper cuts.

Jan's right, in that the typical MySQL user that's building an
unambitious little PHP application doesn't care about the extra
layers. They wouldn't have bought CICS, whether from IBM or from BEA,
or something more modern, like Tuxedo; if they're using MySQL as a
step up from MS Access, "doing things right" wasn't a notion that they
had in their heads to even contemplate.

It's like deciding to prefer Windows because if you visit Office
Depot, Staples, CompUSA, and Circuit City, that's the only system you
see boxed software for; it's not a measure of goodness, but merely the
fact that it's visible, and can be made serviceable enough.

Sleepycat DB can accurately claim to have hundreds of millions of
deployments simply out of the fact that practically every Linux system
links to it. (I see 67 programs in my /usr/bin that link to
libdb3.so.3...) They're obviously far and away the "most popular open
source database." Entertainingly enough, they have a replication
system, too, and even an XA interface to support 2PC :-). No SQL,
though...
--
"cbbrowne","@", "acm.org"
http://www.ntlug.org/~cbbrowne/linux.html
Why do we drive on parkways and park on driveways?

[Christopher Browne]

Martha Stewart called it a Good Thing when aj*@crankycanuc k.ca (Andrew Sullivan) wrote:

On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:

for that is NOT performance. SAP spends that effort multiple times
by implementing their own, custom integrity control and data domain
system in the DB abstraction layer, to gain DB vendor
independence. That abstraction layer is larger than PHP and Apache
together, so this example is IMHO totally irrelevant for the
typical MySQL user.

Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things
efficiently, and that means doing the work in the place where it is
least likely to need to be checked again. For most database
applications, that's inside the database. (I'll not now start my
rant on the mess caused by developers who are careless with this
principle.)

There's a further issue, namely that these "bankrupt" ways were
adopted literally decades ago, and involve the "trillion-dollar"
investments.

Way back when, R/2 was implemented on MVS using IMS, and SAP
implemented their own toolset to manage that, including their own
more-or-less-implicit transaction manager. Thirty years later, they
have ported it to run on systems that didn't exist back then, but it's
still, in essence, a "mainframe" thing, even if you're running it atop
Windows NT and Microsoft's port of Sybase. It persists because
there's 30 years worth of ABAP/4 code customized for a zillion
purposes that SAP can keep on selling.

The problem is not one of carelessness; it is that R/2 was written to
run on databases like IMS, a pre-relational hierarchical system, and
Adabas, which couldn't support having more than 256 tables, once upon
a time... They had to create an ad-hoc variation on CICS, and
starting from scratch would cost trillions.

Even they couldn't afford that. Microsoft has been trying to do some
"reinventio n" of Windows in the new "Longhorn" thing, and despite
having $Billion$ in the bank, it looks like those ambitions are dying
the death of a thousand paper cuts.

Jan's right, in that the typical MySQL user that's building an
unambitious little PHP application doesn't care about the extra
layers. They wouldn't have bought CICS, whether from IBM or from BEA,
or something more modern, like Tuxedo; if they're using MySQL as a
step up from MS Access, "doing things right" wasn't a notion that they
had in their heads to even contemplate.

It's like deciding to prefer Windows because if you visit Office
Depot, Staples, CompUSA, and Circuit City, that's the only system you
see boxed software for; it's not a measure of goodness, but merely the
fact that it's visible, and can be made serviceable enough.

Sleepycat DB can accurately claim to have hundreds of millions of
deployments simply out of the fact that practically every Linux system
links to it. (I see 67 programs in my /usr/bin that link to
libdb3.so.3...) They're obviously far and away the "most popular open
source database." Entertainingly enough, they have a replication
system, too, and even an XA interface to support 2PC :-). No SQL,
though...
--
"cbbrowne","@", "acm.org"
http://www.ntlug.org/~cbbrowne/linux.html
Why do we drive on parkways and park on driveways?