<div dir="ltr">A couple of points:<div><br></div><div>* Mnesia protects you against the scenario where one of your nodes fail. It doesn't automatically protect you against the network splitting, and requires some manual recovery on the flip side of such an event. For rather small clusters, this is manageable by manual operation. Larger systems will be far harder to maintain because the risk of netsplits and node loss goes up whenever you add a new node.</div><div><br></div><div>* I don't know about Wasabi, but Amazon's EC2 nodes are ephemeral in the sense they can go away at a moments notice. And when this happens, the data on the node is gone. Thus, to achieve persistent storage, you must either store data off the EC2 node, presumably in S3, RDS, DynamoDB and so on. Or use an EBS volume, attached to the EC2 node to provide persistent disk space (on which your mnesia database can reside).</div><div><br></div><div>* The game is all about risk mitigation. If you regularly take a mnesia backup and store it into S3, or something like it, you can get speedy recovery to that point in time should the accident happen. If you want better point-in-time-recovery, you can try running two mnesia nodes, but you need to heed two important caveats:</div><div>    - You probably want your nodes to run in different zones so a failure in one zone doesn't take down everything.</div><div>    - Amazons network is brittle and likely to drop connections which are seen as netsplits.</div><div><br></div><div>* Mnesia mitigates risk by assuming the nodes are fairly robust and stable, as well as the network between them. If you buy good expensive hardware, this is a likely assumption and the noise of error will be low. So manual intervention in the case of an error is probably what is needed anyway (to fix the faulty hardware as well).</div><div><br></div><div>* Amazon and other leased environments tend to have brittle network connections and flaky machines. To mitigate this, your system must make no assumptions about stability and handle this up front. Mnesia wasn't really built to work in such an environment.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 29, 2017 at 10:23 PM <<a href="mailto:lloyd@writersglen.com">lloyd@writersglen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Wasabi is a new cloud storage service that promotes lower storage costs and greater speed than Amazon S3:<br>
<br>
<a href="https://wasabi.com/" rel="noreferrer" target="_blank">https://wasabi.com/</a><br>
<br>
During the dev phase I'm running mnesia on the back-end of my current web project. I much like the seamless way that mnesia integrates into Erlang as well as its replication feature. But folks have warned about the hassles of mnesia net splits.<br>
<br>
Problem is that I have no operations experience to objectively weigh options. But I do want to bridge over all points of failure as cost-and-time-effectively as possible.<br>
<br>
So, my question is if and how I can integrate Wasabi (or Amazon S3 for that matter) into my operation to significantly reduce the probability of data loss?<br>
<br>
<br>
Many thanks,<br>
<br>
LRP<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>