Kerker Staffan wrote:
hi
ok, thanks for the update. i kind of dropped that
track as i had all those errors.
with your experience, is that a better solution than
using the t_replicate? i'm only synchronizing two servers.
Well, there is a trade-off between the complexity of a mysql cluster
deployment and the possible inconsistencies introduced by t_replicate.
With mysql cluster, you can always be sure that both of your proxies
have the same, consistent view of the registration state. This comes at
the prize of deploying and maintaining the db cluster. t_replicate is a
lightweight replication mechanism that doesn't ensure registration state
consistency. I like the simplicity of this approach.
Personally, I prefer having a consistent registration state. I also
think that the mysql guys have done a great job in making the cluster
deployment and management as easy as possible.
/Christian
best regards,
/staffan
-----Original Message-----
From: Christian Schlatter [mailto:[EMAIL PROTECTED]
Sent: den 19 september 2007 15:42
To: Kerker Staffan
Cc: Juha Heinanen; users@openser.org
Subject: Re: [OpenSER-Users] OpenSER with MySQL Cluster
Kerker Staffan wrote:
hi
i'm curious about this one. we used to run a dual Openser
installation
with MySQL cluster, but this proved to very unstable (on
the cluster
side).
is this working fine now?
for instance, if one of the mysql cluster nodes was
disconnected, this
could lead to complete cluster shut down, and nodes didn't handle
reconnect very good.
so, we actually switched to the register replication instead...
We're running a mysql 5.0.22 cluster for our two redundant
openser proxies. This setup works very stable for about a year now.
In the beginning our cluster was shutting down itself quite
regularly e.g. after a network failure. Since then we
- are running the management nodes on hosts that are
connected to the data nodes through different network paths
(this is essential, a cluster node needs to be able to solve
the splitbrain problem)
- have added 'StopOnError = 0' to the data node settings
(this causes a data nodes to try to reconnect after it lost
communication to its neighbors, per default, a data node just
shuts itself down)
- added enough DataMemory and IndexMemory for the data nodes
(DataMemory = 1024M, IndexMemory = 64M)
Overall I'm quite pleased with our mysql cluster solution,
although I'd
prefer a solution where the UAs do register with both of our
proxies, so
that there is no need to replicate registration state between
the proxies.
Our mysql cluster basically only contains the 'location'
table since we
store all account data on redundant LDAP/H350 directories.
/Christian
best regards
/Staffan
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian Schlatter
Sent: den 18 september 2007 23:37
To: Juha Heinanen
Cc: users@openser.org
Subject: Re: [OpenSER-Users] OpenSER with MySQL Cluster
Juha Heinanen wrote:
...
unfortunately you then cannot support presence. using
another proxy
for presence is not a solution either, because same users
need both
presence and other sip methods.
What exactly prevents me from using a dedicated presence
server? And why can't I support presence with db_mode=3?
E.g. if I just want to deploy a simple PA using the PRESENCE
module, I don't see any dependencies on USRLOC.
I'm not sure if PUA_USRLOC depends on db_mode<3, but at least
the documentation doesn't mention it. And it looks to me like
I could use
pua_set_publish() from PUA_USRLOC to send a PUBLISH to my
dedicated presence server ;-) ... I haven't tried that though.
by the way, looks like presence related requests are by
far the most
common ones if all sip UAs have presence turned on. it means that
presence would also create biggest db activity.
Yes, I know, SIP presence is very chatty.
/Christian
_______________________________________________
Users mailing list
Users@openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
