<div>Thanks for all the replies. Guess I just need to keep it simple.</div>
<div> </div>
<div>Appreciate it.<br><br></div>
<div class="gmail_quote">On Tue, Apr 20, 2010 at 7:28 PM, Brad Bendy <span dir="ltr"><<a href="mailto:brad.bendy@benganetworks.com">brad.bendy@benganetworks.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi,<br><br>Master-master works very well, if you have that much traffic you can<br>write to both at the same time and then you should be able to load<br>
balance your billing processes between the two, one master would use<br>even keys one would use odd keys so you never have a overlapping primary<br>id.<br><br>>From our experience keep your acc table small and all is well, we only<br>
keep 24-48 hours in the acc table and nightly move/delete to a archive<br>table, if we ever need the original acc entries we still have them and<br>we have had 0 issues with performance<br><br>Ive got one machine that is a dual core Xeon sequence 3000 that can run<br>
4,000+ QPS all day long with no issues, that's on cheap SATA hard drives<br>and it does very well actually.<br><font color="#888888"><br>-Brad<br></font>
<div>
<div></div>
<div class="h5"><br>On Tue, 2010-04-20 at 22:23 +0100, Stanisław Pitucha wrote:<br>> Hi,<br>> You may have different environment at your site, but this is my experience:<br>><br>> - NDB is hard to setup / maintain - it might seem easy at the start<br>
> (trivial even), but when something fails and a node doesn't want to<br>> reconnect to the cluster again, you're left on your own with the source.<br>> Not many people know NDB and since it's not included in the standard<br>
> package anymore, not many will learn. It's also sometimes hard to figure<br>> out which node has problems - sometimes frontend doesn't connect because<br>> of manager problems.<br>> - I don't think you can actually create a monitoring tool which is able<br>
> to report the precise problem for you - many times when I had a node<br>> which could not connect, the only people who could help me were ones on<br>> irc after looking though a long debug log from the node starting up.<br>
> - Opensips schema is simple and trivial to replicate with id skipping.<br>> Whatever you're trying to achieve with NDB, will be very likely possible<br>> with master-master replication between standard mysql hosts.<br>
> - Unless you're handling all the calls of a small city, one host (with<br>> enough memory and cpu for handling databases) is enough to support all<br>> your needs.<br>><br>> After a couple of spectacular failures of the NDB setup, I migrated to a<br>
> master-master replication with one ip failover (so that only one db at a<br>> time gets the actual mysql traffic). I haven't touched it since then.<br>> If you have some experience with managing NDB, or handle enough traffic<br>
> to justify it - go for it. But I would recommend scaling down - most<br>> likely NDB would just add new parts which can fail in new ways.<br>><br>> Stan<br>><br>> PS. I tried this around 2 years ago - things might have changed since then.<br>
><br>> _______________________________________________<br>> Users mailing list<br>> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--<br>*--*--*--*--*--*<br>Duane<br>*--*--*--*--*--*<br>--<br>