Re: [ClusterLabs] copy file

[Ken Gaillot]

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 :
> > 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 :
> > > > 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  > > > > >:
> > > > >
> > > > >     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 

Re: [ClusterLabs] copy file

[Mevo Govo]

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.





2018-03-08 20:12 GMT+01:00 Ken Gaillot :

> 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 :
> > > 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  > > > >:
> > > >
> > > > 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 
> > > >
> > > > 

Re: [ClusterLabs] copy file

[Ken Gaillot]

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 :
> > 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  > > >:
> > >
> > >     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 
> > >
> > >     ___
> > >     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
> > >
> > >
> > >
> > >
> > > ___
> > > 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_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 
___
Users mailing list: Users@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/users

Project Home: 

Re: [ClusterLabs] copy file

[Mevo Govo]

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.


2018-03-07 10:20 GMT+01:00 Klaus Wenninger :

> 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  > >:
> >
> > 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 >
> > ___
> > 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
> >
> >
> >
> >
> > ___
> > 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
>
> ___
> 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
>
___
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

Re: [ClusterLabs] copy file

[Klaus Wenninger]

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  >:
>
> 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 >
> ___
> 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
>
>
>
>
> ___
> 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

___
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

Re: [ClusterLabs] copy file

[Mevo Govo]

Thanks for advices, I will try!
lados.

2018-03-05 23:29 GMT+01:00 Ken Gaillot :

> 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.
> --
> Ken Gaillot 
> ___
> 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
>
___
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

Re: [ClusterLabs] copy file

[Ken Gaillot]

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.
-- 
Ken Gaillot 
___
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

[ClusterLabs] copy file

[Mevo Govo]

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.
___
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