Aaron Stone writes:
This has been discussed at length on the mailing list; see the archives
for pertinent arguments on both sides. In a nutshell: don't do it.
Aaron
most of the arguments were not sufficient to drive me away from the whole
idea, assuming will not bring a solution nor will it make it a fact. since
gpl permits forking, that`s going to happen, dbmail-rds, the main approach:
redundant distributed system. Some of the modules will go with Berkeley
license, and of course the base will remain GPL. Hope that makes some sense.
Anyway i`m trying to find some spare time to finish the paper regarding this
fork, hopefully it will be done before the end of April. Some of the points
are(and basic todo list):
1) Better sequences, targeting at generic generator for sequences(indexes,
blahblah). That includes dealing with the problems concerning unique login
names and that kinda stuff, in general uniqueness and randomness(trying to
stay away from any form of overlaping,collisions and duplicates) ,therefor i
suppose we`re going to use as base genetic algorithms. To re-design the db
backend and make it more generic for further add-ins and changes.
2) GRS or generic reporting system, kinda of a heartbeat monitor, for
fail-over support(including other small things).
3) Parallel operations and clustering (Josse`s example)
..)
n)...
in a multi mx environment, more than a week work in a productional
environment - 0 problems(with my lousy solution:)). That doesnt mean it`s
not going to fall or fail. But calculating the risk and penetrating the
system correctly gives a good overview of the things that might happen and
might not.
that`s my very own opinion.
On Sat, 5 Apr 2003, Michael Kummer wrote:
hi again!
because I can't find any hint in the mysql docs about using master-master
replication I'd be very happy if you could explain it how you managed it.
easy, make both of them masters, but be carefull.
My opinion: Test it, try it, tell me if it works or not, any ideas and
sugestions are welcome.
have fun and best of luck.
cheers,
-lou
--
Network Infrastructure/Security Analyst
Lou Kamenov [EMAIL PROTECTED] [EMAIL PROTECTED]
AEYE R&D - http://www.aeye.net AEYE Technologies - http://www.aeye.biz
phone: +44 (0) 20 8879 9832 fax: +44 (0) 7092 129079
mobile: +44 (0) 79 0551 4036 PGP Key ID - 0xA297084A
"Wherever we can, we leverage our solutions with Artificial Intelligence (AI
- 'Aeye'). This is a central theme to our approach since we are without
reservation in the belief that tomorrows applications will have to be very
smart in order to be ordinary" - Dr. Tim Stucke, AEYE CTO
