<div dir="ltr"><div><div><div>Hi, <br></div>Thank for advices, I'm thinking an optimal config for us. While the DB is working, it would do native DB replication. But oracle needs synchronized controlfiles when it starts normally. I can save the file before overwrite it. Currently I mean this (c1, c2, c3, c4, c5, c6 are control files):<br></div><br>c1: on node A, local file system<br></div>
c2:
on node A, on DRBD device1<br><div><div>c3:
on node A, on DRBD device2 (FRA)<br></div></div><div><div><div><div>
<div><div>
<div><div>c4:
on node B, on DRBD device2 (FRA)<br></div></div><div><div><div><div>
<div><div></div></div></div></div></div></div>
<div></div>
c5:
on node B, on DRBD device1<br></div></div><div><div><div><div>c6: on node B, local file system<br>
<br></div><div>
c2+c3 is a "standard" oracle config. c2 is replicated into FRA (fast recovery area of oracle).
c1 (and c6) is just if all data in DRBD is lost.<br>c1, c2, c3, c4, c5 (but not c6) are in sync while DB runs on node A. (c1,c2,c3: native DB replication, c2-c5, c3-c4 DRBD replication, protocol C)<br></div><div>When I switch from node A to node B, c6 is out of sync (older version). I can (and I will) save it before overwrite by c5. But if c5 is corrupt, manual repair is needed, and there are other replications to repair it (c4, c3, c2, c1)<br></div></div></div></div>If c1 and c6 would be the same file on an nfs filesystem, there would be a replication outside of DRBD without this "copy sync" problem. But in this case, the fail of only one component (the nfs) would cause unavailable the oracle DB on both node. (oracle DB stops if either of controlfile is lost or corrupted. No automatic reapair happens)<br></div><div>As I think, the above consideration is similar to 3 node.<br></div>
<div>If we trust DRBD, no c1 and c6 would be needed, but we are new users of DRBD.<br></div><div></div>
Thanks: lados.<br></div>
<br><br><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-08 20:12 GMT+01:00 Ken Gaillot <span dir="ltr"><<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 2018-03-08 at 18:49 +0100, Mevo Govo wrote:<br>
> Hi, <br>
</span><span class="">> thanks for advice and your intrest.<br>
> We would use oracle database over DRBD. Datafiles (and control and<br>
> redo files) will be on DRBD. FRA also (on an other DRBD device). But<br>
> we are new in DRBD, and DRBD is also a component what can fails. We<br>
> plan a scenario to recover the database without DRBD (without data<br>
> loss, if possible). We would use nfs or local filesystem for this. If<br>
> we use local FS, the control file is out of sync on the B node when<br>
> switch over (from A to B). We would copy controlfile (and redo files)<br>
> from DRBD to the local FS. After this, oracle can start, and it keeps<br>
> the controlfiles syncronized. If other backup related files (archlog,<br>
> backup) are also available on the local FS of either node, we can<br>
> recover the DB without DRBD (without data loss)<br>
> (I know it is a worst case scenario, because if DRBD fails, the FS on<br>
> it should be available at least on one node)<br>
> Thanks: lados.<br>
<br>
</span>Why not use native database replication instead of copying files?<br>
<br>
Any method getting files from a DRBD cluster to a non-DRBD node will<br>
have some inherent problems: it would have to be periodic, losing some<br>
data since the last run; it would still fail if some DRBD issue<br>
corrupted the on-disk data, because you would be copying the corrupted<br>
data; and databases generally have in-memory state information that<br>
makes files copied from a live server insufficient for data integrity.<br>
<br>
Native replication would avoid all that.<br>
<div class="HOEnZb"><div class="h5"><br>
> 2018-03-07 10:20 GMT+01:00 Klaus Wenninger <<a href="mailto:kwenning@redhat.com">kwenning@redhat.com</a>>:<br>
> > On 03/07/2018 10:03 AM, Mevo Govo wrote:<br>
> > > Thanks for advices, I will try!<br>
> > > lados.<br>
> > ><br>
> > > 2018-03-05 23:29 GMT+01:00 Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a><br>
> > > <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>>>:<br>
> > ><br>
> > > On Mon, 2018-03-05 at 15:09 +0100, Mevo Govo wrote:<br>
> > > > Hi,<br>
> > > > I am new in pacemaker. I think, I should use DRBD instead<br>
> > of copy<br>
> > > > file. But in this case, I would copy a file from a DRBD to<br>
> > an<br>
> > > > external device. Is there a builtin way to copy a file<br>
> > before a<br>
> > > > resource is started (and after the DRBD is promoted)? For<br>
> > example a<br>
> > > > "copy" resource? I did not find it. <br>
> > > > Thanks: lados.<br>
> > > ><br>
> > ><br>
> > > There's no stock way of doing that, but you could easily<br>
> > write an<br>
> > > agent<br>
> > > that simply copies a file. You could use ocf:pacemaker:Dummy<br>
> > as a<br>
> > > template, and add the copy to the start action. You can use<br>
> > standard<br>
> > > ordering and colocation constraints to make sure everything<br>
> > happens in<br>
> > > the right sequence.<br>
> > ><br>
> > > I don't know what capabilities your external device has, but<br>
> > another<br>
> > > approach would be to an NFS server to share the DRBD file<br>
> > system, and<br>
> > > mount it from the device, if you want direct access to the<br>
> > original<br>
> > > file rather than a copy.<br>
> > ><br>
> ><br>
> > csync2 & rsync might be considered as well although not knowing<br>
> > your scenario in detail it is hard to tell if it would be overkill.<br>
> ><br>
> > Regards,<br>
> > Klaus<br>
> ><br>
> > > --<br>
> > > Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
> > ><br>
> > > _____________________________<wbr>__________________<br>
> > > Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> > > <mailto:<a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><wbr>><br>
> > > <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.<wbr>org/mailman/listinfo/users</a><br>
> > > <<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.<wbr>org/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:<br>
> > > <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>
> > > <<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>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> > > <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://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_Scra" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scra</a><br>
> > tch.pdf<br>
> > > Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> > <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://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_Scratc" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratc</a><br>
> > h.pdf<br>
> > Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
> ><br>
><br>
> ______________________________<wbr>_________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://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" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch</a>.<br>
> pdf<br>
> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
</font></span><span class="im HOEnZb">______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
</span><div class="HOEnZb"><div class="h5"><a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://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>