[isf-wifidog] WiFi Dog auth server mirroring

Benoit Grégoire bock at step.polymtl.ca
Lun 22 Aou 10:45:57 EDT 2005


On August 21, 2005 04:51 pm, Scott Tully wrote:
> > So was I, the two quotes above are from:
> >  16.8. Cluster Limitations in MySQL 4.1
> > (There is also a chapter on the changes in 5.0, but the two limitation
> > haven't been lifted)
>
> The limitation refers to using Replication with Clustering, not just
> clustering.  It's only a limitation if you need to do that.  I am not
> even 100% clear what this means... i guess the mysql server (sql node)
> will insert/update a ndb table which then is replicated simultaneously
> to a slave server?   In my feeble mind i can not even contemplate why
> you would want to do that....  unless you are replicating to a second
> ndb cluster.  Maybe i just don't see it from your view.
>
> What I would think might me a problem is that the data storage nodes
> need to have a good connection with very little latency between the
> storage nodes and the sql nodes.  ie, be on the same LAN.  This would
> require network redundancy to be a good solution for HA.

Indeed, I'm not sure we are trying to solve the same problem.  We want 
gegographically dispersed auth servers.  A cluster storage engine would 
probably not perform well in this environement.  

 The cost of duplicating that server for clustering is simply beyond our 
current financial means. It's not perfect, but our current setup of a single 
server-class auth server with RAID disks in a data center is reliable enough 
for us to wait for a better solution. 

Our prior problem was lack of reliability of auth server connectivity, which 
is not solvable by classic clustering.

Clustering is a good way to increase hardware reliability and capacity, but 
that's simply not a significant problem for us.

> > Note that I am not saying that MySQL clusters are worthless, just that
> > they aren't yet a very general solution.  It would require quite a bit of
> > MySQL specific work to make it run.
>
> This is what i feel is the actual reason for you not accepting
> clustering as an alternative. MySQL does not adhere to standards
> enough for you to consider using it.

Yes and no.  Since the decision was made to support multiple RDBMS (including 
MySql for 1.0), it's kind of a matter of principals that we try to stick with 
reasonnably portable yet reasonnably modern (fk, check constraints, 
transactions, etc) features. But if someone can provide a sufficiently 
modular patch, I'd be glad to accept it.  But considering how extensively we 
rely on foreign keys for deletes and for defending against programming 
errors, that would be hard to pull off.

One way or another, the first step is to get MySql support working again...

-- 
Benoit Grégoire, http://benoitg.coeus.ca/
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
Url: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20050822/780e975b/attachment.pgp


More information about the WiFiDog mailing list