On Fri, 2018-03-09 at 10:35 +0100, Mevo Govo wrote: > Hi, > 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): > > c1: on node A, local file system > c2: on node A, on DRBD device1 > c3: on node A, on DRBD device2 (FRA) > c4: on node B, on DRBD device2 (FRA) > c5: on node B, on DRBD device1 > c6: on node B, local file system > > 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. > 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) > 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) > 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) > As I think, the above consideration is similar to 3 node. > If we trust DRBD, no c1 and c6 would be needed, but we are new users > of DRBD. > Thanks: lados.
I'm not familiar with Oracle, so I'm making some guesses here ... If I follow you correctly, you have an Oracle configuration consisting of two parts (c2+c3), and you're using DRBD to mirror these to another node (c4+c5, which are really synchronized instances of c2+c3). Somehow you are saving a copy of each file outside DRBD (c1+c6). Before starting the db, you want a resource that checks whether the original config needs repair, and if so, copy it from the backup outside DRBD. It sounds like you should make a copy of the oracle agent, and modify its start action to do what you want. > 2018-03-08 20:12 GMT+01:00 Ken Gaillot <kgail...@redhat.com>: > > On Thu, 2018-03-08 at 18:49 +0100, Mevo Govo wrote: > > > Hi, > > > thanks for advice and your intrest. > > > We would use oracle database over DRBD. Datafiles (and control > > and > > > redo files) will be on DRBD. FRA also (on an other DRBD device). > > But > > > we are new in DRBD, and DRBD is also a component what can fails. > > We > > > plan a scenario to recover the database without DRBD (without > > data > > > loss, if possible). We would use nfs or local filesystem for > > this. If > > > we use local FS, the control file is out of sync on the B node > > when > > > switch over (from A to B). We would copy controlfile (and redo > > files) > > > from DRBD to the local FS. After this, oracle can start, and it > > keeps > > > the controlfiles syncronized. If other backup related files > > (archlog, > > > backup) are also available on the local FS of either node, we can > > > recover the DB without DRBD (without data loss) > > > (I know it is a worst case scenario, because if DRBD fails, the > > FS on > > > it should be available at least on one node) > > > Thanks: lados. > > > > Why not use native database replication instead of copying files? > > > > Any method getting files from a DRBD cluster to a non-DRBD node > > will > > have some inherent problems: it would have to be periodic, losing > > some > > data since the last run; it would still fail if some DRBD issue > > corrupted the on-disk data, because you would be copying the > > corrupted > > data; and databases generally have in-memory state information that > > makes files copied from a live server insufficient for data > > integrity. > > > > Native replication would avoid all that. > > > > > 2018-03-07 10:20 GMT+01:00 Klaus Wenninger <kwenn...@redhat.com>: > > > > On 03/07/2018 10:03 AM, Mevo Govo wrote: > > > > > Thanks for advices, I will try! > > > > > lados. > > > > > > > > > > 2018-03-05 23:29 GMT+01:00 Ken Gaillot <kgail...@redhat.com > > > > > <mailto:kgail...@redhat.com>>: > > > > > > > > > > On Mon, 2018-03-05 at 15:09 +0100, Mevo Govo wrote: > > > > > > Hi, > > > > > > I am new in pacemaker. I think, I should use DRBD > > instead > > > > of copy > > > > > > file. But in this case, I would copy a file from a DRBD > > to > > > > an > > > > > > external device. Is there a builtin way to copy a file > > > > before a > > > > > > resource is started (and after the DRBD is promoted)? > > For > > > > example a > > > > > > "copy" resource? I did not find it. > > > > > > Thanks: lados. > > > > > > > > > > > > > > > > There's no stock way of doing that, but you could easily > > > > write an > > > > > agent > > > > > that simply copies a file. You could use > > ocf:pacemaker:Dummy > > > > as a > > > > > template, and add the copy to the start action. You can > > use > > > > standard > > > > > ordering and colocation constraints to make sure > > everything > > > > happens in > > > > > the right sequence. > > > > > > > > > > I don't know what capabilities your external device has, > > but > > > > another > > > > > approach would be to an NFS server to share the DRBD file > > > > system, and > > > > > mount it from the device, if you want direct access to > > the > > > > original > > > > > file rather than a copy. > > > > > > > > > > > > > csync2 & rsync might be considered as well although not knowing > > > > your scenario in detail it is hard to tell if it would be > > overkill. > > > > > > > > Regards, > > > > Klaus > > > > > > > > > -- > > > > > Ken Gaillot <kgail...@redhat.com <mailto:kgaillot@redhat. > > com> > > > > > > > > > > _______________________________________________ > > > > > Users mailing list: Users@clusterlabs.org > > > > > <mailto:Users@clusterlabs.org> > > > > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > > <https://lists.clusterlabs.org/mailman/listinfo/users> > > > > > > > > > > Project Home: http://www.clusterlabs.org > > > > > Getting started: > > > > > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > > > > <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf> > > > > > Bugs: http://bugs.clusterlabs.org > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Users mailing list: Users@clusterlabs.org > > > > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > > > > > > > Project Home: http://www.clusterlabs.org > > > > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_ > > Scra > > > > tch.pdf > > > > > Bugs: http://bugs.clusterlabs.org > > > > > > > > _______________________________________________ > > > > Users mailing list: Users@clusterlabs.org > > > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > > > > > Project Home: http://www.clusterlabs.org > > > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Sc > > ratc > > > > h.pdf > > > > Bugs: http://bugs.clusterlabs.org > > > > > > > > > > _______________________________________________ > > > Users mailing list: Users@clusterlabs.org > > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > > > Project Home: http://www.clusterlabs.org > > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scra > > tch. > > > pdf > > > Bugs: http://bugs.clusterlabs.org > > -- > > Ken Gaillot <kgail...@redhat.com> > > _______________________________________________ > > Users mailing list: Users@clusterlabs.org > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc > > h.pdf > > Bugs: http://bugs.clusterlabs.org > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > https://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch. > pdf > Bugs: http://bugs.clusterlabs.org -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org