Caution: You are not going to like my answers.
> and VMWare
> shared storage
Why? Seems like scalability should plan on having dedicated hardware.
> replication
The best choice
> multi-mastering
Dual-Master gives good HA
> DRBD
Partially solves one subset of HA; don't bother with it; set your sights
higher.
> clustering
maybe
> PARTITION
Only if you have really big tables
> Sharding
Only if you are writing faster than a single server can handle -- I say
that even for Dual-Master setups.
> With the primary application that will be using the database, writes
and reads cannot be split off from each other.
That is probably false. Yes, it will take some deeper thought to
understand how to split them, or split them in certain situations.
> We do not expect to be especially write-heavy.
Skip Sharding, use readonly slaves.
> We have shared storage
Single-point-of-failure --> there goes your HA.
> We have VMWare HA which already monitors hosts and brings them up
within minutes elsewhere if we lose a host.
That is thinking at the hardware level. But will it really work for
Dual-Master?
> another instance of our system running in the Amazon cloud
Bother. More complexity.
On 3/29/12 6:23 PM, Wes Modes wrote:
First, thank you in advance for good solid suggestions you can offer. I
suppose someone has already asked this, but perhaps you will view it as
a fun challenge to meet my many criteria with your suggested MySQL
architecture.
I am working at a University on a high-profile database driven project
that we expect to be slammed within the first few months. Since this is
a new project and one that we expect to be popular, we don't know what
kind of usage to expect, but we want to be prepared. Therefore, we are
building in extra capacity.
Our top goals are scalability and high availability, provided we hope
through multiple MySQL nodes and VMWare functionality. I've been
surprised that there are not more MySQL architects trying to meet these
high-level goals using virtualization and shared storage (or at least
they do not seem to be writing about it).
I've looked at replication, multi-mastering, DRBD, clustering,
partitioning, and sharding.
Here's what we got, and some of our constraints:
* We are concerned that One Big Database instance won't be enough to
handle all of the queries, plus it is a single point of failure.
Therefore, multiple nodes are desirable.
* With the primary application that will be using the database, writes
and reads cannot be split off from each other. This limitation alone,
rules out replication, MMM, and a few other solutions.
* We do not expect to be especially write-heavy.
* We have shared storage in the form of an iSCSI SAN. We'd like to
leverage the shared storage, if possible.
* We have VMWare HA which already monitors hosts and brings them up
within minutes elsewhere if we lose a host. So some of the suggested HA
solutions are redundant.
* We expect to have another instance of our system running in the Amazon
cloud for the first few months while the traffic is high, so we may take
advantage of RDS, though an exact duplicate of our local system will
save us development work.
Thanks for any advice you can give.
Wes Modes
--
Rick James - MySQL Geek
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
