<div dir="ltr">DRBD is absolutely compatible with mysql/postgres.<br><br>In my experience, with a 10G pipe for block replication, there's also basically no performance degradation compared to native disk writes, even with an SSD array.<br><br>> <span style="font-size:12.8px">I've always favored native replication over disk replication for</span><br style="font-size:12.8px"><span style="font-size:12.8px">databases. I'm not sure that's a necessity, but I would think the</span><br style="font-size:12.8px"><span style="font-size:12.8px">biggest advantage is that with disk replication, you couldn't run the</span><br style="font-size:12.8px"><span style="font-size:12.8px">database server all the time, you'd have to start it (and its VM in your</span><br style="font-size:12.8px"><span style="font-size:12.8px">case) after disk failover.<br><br>This is true, you have to start mysql/the vm during failover, but in my experience usually that is very fast (depending on mysql/vm configuration).  Also, depending on what replication tools you are using, you'd still have to promote the slave to a master, which might save seconds or less compared to starting mysql (which, I recognize, could be important).  Note that I am unfamiliar with methods of postgres replication.  <br><br>I think a big advantage compared to native replication is that DRBD offers synchronous replication at the block level as opposed to the transaction level.  I have not run my own tests, but my vicarious experience with tools such as Galera or other synchronous forms of SQL replication indicate that there may be a significant performance hit based on workload.  Obviously, there's no significant performance hit if you are doing mysql native asynchronous replication (I guess as long as you aren't spending all your i/o on the master on your binlogs), but then you are relying on asynchronous processes to keep your data safe and available.  Perhaps that is not a big deal, I am not well versed in that level of replication theory.<br><br>> </span><span style="font-size:12.8px">physical proximity so that environmental factors could</span><br style="font-size:12.8px"><span style="font-size:12.8px">take down the whole thing.</span><br style="font-size:12.8px"><span style="font-size:12.8px"><br>Literal server fires come to mind.<br><br>@OP, I agree with Ken that a multi-datacenter setup is ideal if your application can deal with its various caveats and may be worth investigating since the advantages of moving to a DRBD setup doesn't eliminate any more problems than a multi-dc setup would </span><span style="font-size:12.8px">as long as your SAN is already set up on independent electrical circuits and separate networking stacks to begin with.  E.g., both a multi-server and multi-center setup would protect from small </span><span style="font-size:12.8px">disasters that take out the whole server, but a DRBD setup does not add much more than that whereas a multi-center setup would also protect from large-scale disaster.   DRBD and a SAN would also both suffer from a building-wide power outage.  Do you have generators?</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 1:30 PM, Digimer <span dir="ltr"><<a href="mailto:lists@alteeve.ca" target="_blank">lists@alteeve.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-07-17 05:51 AM, Lentes, Bernd wrote:<br>
> Hi,<br>
><br>
> i established a two node cluster with two HP servers and SLES 11 SP4. I'd like to start now with a test period. Resources are virtual machines. The vm's reside on a FC SAN. The SAN has two power supplies, two storage controller, two network interfaces for configuration. Each storage controller has two FC connectors. On each server i have one FC controller with two connectors in a multipath configuration. Each connector from the SAN controller inside the server is connected to a different storage controller from the SAN. But isn't a SAN, despite all that redundancy, a SPOF ?<br>
> I'm asking myself if a DRBD configuration wouldn't be more redundant and high available. There i have two completely independent instances of the vm.<br>
> We have one web application with a databse which is really crucial for us. Downtime should be maximum one or two hours, if longer we run in trouble.<br>
> Is DRBD in conjuction with a database (MySQL or Postgres) possible ?<br>
><br>
><br>
> Bernd<br>
<br>
</span>DRBD any day.<br>
<br>
Yes, even with all the redundancy, it's a single electrical/mechanical<br>
device that can be taken offline by a bad firmware update, user error,<br>
etc. DRBD gives you full mechanical and electrical replication of the<br>
data and has survived some serious in-the-field faults in our Anvil!<br>
system (including a case where three drives were ejected at the same<br>
time from the node hosting the VMs, and the servers lived).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Digimer<br>
Papers and Projects: <a href="https://alteeve.com/w/" rel="noreferrer" target="_blank">https://alteeve.com/w/</a><br>
"I am, somehow, less interested in the weight and convolutions of<br>
Einstein’s brain than in the near certainty that people of equal talent<br>
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>