Multi-master does nothing for scaling writes.
DRDB does not solve much in the HA arena. What if the building with the
DRDB goes dark?
NDB Clustering has size limitations.
Manually sharding via client code is the only practical solution to
write-scaling in MySQL today.
Replication gives you virtually unlimited _read_ scaling.
High Availablility -> slave in distant colocation -> long latency ->
synchronous may be too slow.
Synchronous? There are partial solutions:
* For critical things, talk only to the master
* Use a cookie (etc) to determine if the client app needs to see what
it just wrote. (especially useful in Web app)
* Dynamically try slave, check Seconds_Behind_Master, then continue
with slave, or switch to master
* As above, but check a sequence counter that gets replicated as the
last step in any write operation.
Rick James
MySQL Geeks - Consulting & Review
> -----Original Message-----
> From: ewen fortune [mailto:ewen.fortune@stripped]
> Sent: Monday, May 19, 2008 11:00 AM
> To: Andrew Martin
> Cc: cluster@stripped; replication@stripped
> Subject: Re: Recommendations for upscaling
>
> Hi Andrew,
>
> On Mon, May 19, 2008 at 7:32 PM, Andrew Martin
> <sublimino@stripped> wrote:
> > @Jeff
> >> For our needs, scalability was a lesser factor than
> servicability or
> >> reliability.
> >
> > This is also a key concern, from what I've looked at today I don't
> > believe replication alone is sufficient.
> >
> >> - Are other application currently running on your db
> server that would
> >> limit the system resources available to MySQL?
> >
> > Yes, apache, qmail, svn etc
> >
> >> - Can your hardware easily expand to accomodate growth?
> >
> > We can look at the feasibility of any solution, although we would
> > prefer to aim for more servers rather than higher spec hardware.
> >
> >> - Is a small percentage of query activity consuming
> inordinate resources
> >> on your server? If so, could these be offloaded to a
> replicated server,
> >> such as for report generation?
> >
> > As this is an accounting platform data consistency is vital - report
> > summaries etc occur all the time. The most intensive writes (ie mail
> > merges) have already been offloaded to another machine.
> >
> > @Jimmy
> >> One option for synchronous replication + MySQL is to take
> a look at DRBD.
> >>
> >> http://www.mysql.com/products/enterprise/drbd.html
> >
> > This looks like a good solution; how well does this scale (without
> > replication) - is it only possible to run two synchronous servers? I
> > believe that any asynchronicity will compromise our service.
>
> At the moment MySQL/DRDB does not support Active/Active architectures,
> therefore its only a HA solution and not a scalability solution.
>
> >
> > Finally could somebody please clarify the advantages of automated IP
> > failover over automated database failover?
>
> In the case of MySQL/DRDB the two instances of the database share the
> same IP and therefore the clients can always find "the database" at
> this_ip, simply having a second instance of the database running on a
> spare machine implies client re-configuration.
>
> The basic rules are (and please correct me if I am wrong):
> MySQL + Replication = Single write master plus many read slaves =
> Scale and HA read ops
> MySQL/DRDB = Active/Passive Database instances = HA read / write ops
> MySQL NDB Cluster = Multiple SQL and Storage nodes = Scale
> and HA read / write
>
> Now its possible to setup multi-master replication, but that still has
> the issues related to asynchronous replication.
> MySQL/DRDB can be setup in conjunction with normal replication to
> allow scalable reads and HA writes
> MySQL NDB Cluster is great for particular schemas and datasets, but
> there are some restrictions such as the lack of foreign key support
> etc
>
> Perhaps you could consider some sort of Partitioning/Sharding to scale
> across many hosts or perhaps offload only a part of the application to
> something like the NDB cluster. (A typical example use is to offload
> your flight data browsing for your airline and then do the important
> stuff somewhere else)
>
> Ewen
>
> >
> > Again I apologise for cross posting to the replication and
> cluster lists.
> >
> > Thanks for reading,
> >
> >
> > Andrew Martin
> >
> > --
> > MySQL Cluster Mailing List
> > For list archives: http://lists.mysql.com/cluster
> > To unsubscribe:
> http://lists.mysql.com/cluster?unsub=1
> >
> >
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe:
> http://lists.mysql.com/replication?unsub=1
>
>
