<div dir="ltr">Sounds interesting, I have a branch which reduces the number of locks during table copying at startup,<div>so that will improve the startup time for large systems.</div><div><br></div><div>But this sounds interesting, send the PR and I will take a better look at it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 28, 2022 at 5:59 PM k32 <<a href="mailto:k32@posteo.net">k32@posteo.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
We've been experimenting with the ways to make large Mnesia clusters<br>
more viable. Our basic idea is to move away from full-mesh topology to a<br>
"mesh+star" topology: a small part of the cluster behaves like a regular<br>
mnesia cluster (we call it core cluster) connected in a full mesh, but<br>
the rest of the nodes are read-only; they passively and asynchronously<br>
replicate transactions from the core cluster over custom protocol, and<br>
delegate write operations to the core nodes via RPC, hence "star".<br>
<br>
So far this approach looks quite promising, we've been able to achieve<br>
decent throughput in 20+ node clusters, so this may be a possible<br>
solution to the mnesia scalability challenge. But we had to patch mnesia<br>
a bit: <a href="https://github.com/emqx/otp/pull/16/files" rel="noreferrer" target="_blank">https://github.com/emqx/otp/pull/16/files</a> (the initial idea to<br>
rely on the events alone proved to introduce too much overhead).<br>
<br>
Ideally, we would like to contribute this patch upstream, so we're<br>
seeking the opinion from the OTP team. Hook API may be of use for other<br>
things too. Not sure if this is the right channel, though.<br>
<br>
--<br>
BR<br>
</blockquote></div>