<div dir="ltr">Writing to disk isn't a uniquely mongodb issue - even many SQL dbs have configurable options for write durability.<div>But for failover replication, the writing to disk is less of the issue than the latency of the replication...</div>
<div>-Avi<br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 1:13 AM, Juan Jose Comellas <span dir="ltr"><<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">You can modify this behavior in MongoDB by changing the "write concern" [1] to ensure that the MongoDB client only returns to the caller when at least one of the replicas has acknowledged the data. The problem is that if you do that the performance drops dramatically. In my opinion, MongoDB is only suitable for storing non-critical data. I would never use it for a failover solution with FreeSWITCH.<div>
<br></div><div>BTW, moving from a relational database to a NoSQL one is not trivial at all, especially if your application requires any kind of transactionality from the DB.<br><div class="gmail_extra"><br></div><div class="gmail_extra">
[1] <a href="http://docs.mongodb.org/manual/core/write-concern/" target="_blank">http://docs.mongodb.org/manual/core/write-concern/</a><div><div class="h5"><br><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 5:19 PM, Patrick Lists <span dir="ltr"><<a href="mailto:freeswitch-list@puzzled.xs4all.nl" target="_blank">freeswitch-list@puzzled.xs4all.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 08/01/2013 09:45 PM, <a href="mailto:john@millican.us" target="_blank">john@millican.us</a> wrote:<br>
[snip]<br>
<div>> I have used many<br>
> SQL db and a few NoSQL and the NoSQL are much faster, easier to scale,<br>
> and just plain more fun. My opinion and of course YMMV<br>
<br>
</div>Doesn't MongoDB acknowledge a write when it still has the data in mem as<br>
opposed to written on disk? So when the power fails and both FreeSWITCH<br>
server 1 and MongoDB server 1 are down there was data in memory that has<br>
not been replicated to MongoDB server 2. How is that going to result in<br>
proper failover? How can you fire up FreeSWITCH server 2 with all call<br>
data when MongoDB server 2 does not have all the call data? I'm no NoSQL<br>
expert so would love to hear how a NoSQL based solution could do the job<br>
reliably.<br>
<br>
Regards,<br>
Patrick<br>
<div><div><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div></div>