f



GT.M recovery procedure from journal in case of crash

Hi.

I'm using GT.M ver V6.2-000 Linux x86_64 and trying to implement journaling for database recovery in case of server unexpected shutdown.
I've carefully read UNIX Administration and Operations Guide at fisglobal.com and tried to use journaling on test database with this command:

mupip set -journal=before,s,ep=1 -region TEST

I write a program, that writes numbers to global from 1 to 100000000 with 0.1 second hang and shows current number in console:

F I=1:1:100000000 H .1 W !,I S ^TEST(I)=I

then I run this program and after a while physically shutdown the server.
Than I start it again and run integrity check by:

mupip integ -fast

and it tells me, that there are some problem in database and I should run recover procedure. I run it by command:

mupip journal -recover -backward "*"

After successful recover I check global TEST and find out, that the last number in console before shutdown was e.g. 715 and in TEST last index now is 712.

So, the question is - it is a normal situation, that I've lost some writes to disk after recovery, or I did something wrong? Is there any way to prevent that loss?
0
UTF
12/22/2016 11:14:59 AM
comp.lang.mumps 1621 articles. 0 followers. Post Follow

4 Replies
477 Views

Similar Articles

[PageSpeed] 47

On Thursday, December 22, 2016 at 6:14:59 AM UTC-5, =D0=9C=D0=B8=D1=85=D0=
=B0=D0=B8=D0=BB =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB wrote:
> Hi.
>=20
> I'm using GT.M ver V6.2-000 Linux x86_64 and trying to implement journali=
ng for database recovery in case of server unexpected shutdown.
> I've carefully read UNIX Administration and Operations Guide at fisglobal=
..com and tried to use journaling on test database with this command:
>=20
> mupip set -journal=3Dbefore,s,ep=3D1 -region TEST
>=20
> I write a program, that writes numbers to global from 1 to 100000000 with=
 0.1 second hang and shows current number in console:
>=20
> F I=3D1:1:100000000 H .1 W !,I S ^TEST(I)=3DI
>=20
> then I run this program and after a while physically shutdown the server.
> Than I start it again and run integrity check by:
>=20
> mupip integ -fast
>=20
> and it tells me, that there are some problem in database and I should run=
 recover procedure. I run it by command:
>=20
> mupip journal -recover -backward "*"
>=20
> After successful recover I check global TEST and find out, that the last =
number in console before shutdown was e.g. 715 and in TEST last index now i=
s 712.
>=20
> So, the question is - it is a normal situation, that I've lost some write=
s to disk after recovery, or I did something wrong? Is there any way to pre=
vent that loss?

Unless you are using Transaction Processing, there is a small window during=
 which journal writes are not "hardened". For applications that don't use T=
P, look at the JNLFLUSH and JNLWAIT keywords of the VIEW command to create =
application checkpoints.

Regards
-- Bhaskar
0
K
12/22/2016 7:39:48 PM
Thanx for your answer. Could you please tell me, how TP will help? If I understand correctly, there could be a situation, when crash occurs while current transaction is not commited yet, so it will be lost, or not?
0
UTF
12/23/2016 5:46:48 AM
On Friday, December 23, 2016 at 12:46:49 AM UTC-5, =D0=9C=D0=B8=D1=85=D0=B0=
=D0=B8=D0=BB =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB wrote:
> Thanx for your answer. Could you please tell me, how TP will help? If I u=
nderstand correctly, there could be a situation, when crash occurs while cu=
rrent transaction is not commited yet, so it will be lost, or not?

A transaction that has not committed has not happened. A transaction that h=
as happened is permanent. That's what Atomicity and Durability mean.

Regards
-- Bhaskar
0
K
12/23/2016 3:16:51 PM
On Friday, December 23, 2016 at 10:16:52 AM UTC-5, K.S. Bhaskar wrote:
> On Friday, December 23, 2016 at 12:46:49 AM UTC-5, =D0=9C=D0=B8=D1=85=D0=
=B0=D0=B8=D0=BB =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB wrote:
> > Thanx for your answer. Could you please tell me, how TP will help? If I=
 understand correctly, there could be a situation, when crash occurs while =
current transaction is not commited yet, so it will be lost, or not?
>=20
> A transaction that has not committed has not happened. A transaction that=
 has happened is permanent. That's what Atomicity and Durability mean.
>=20
> Regards
> -- Bhaskar

One more thought: if you are not using MUPIP SET JOURNAL SYNC_IO, there is =
additional buffering in the file system cache between GT.M's journal buffer=
s and persistent storage.

Regards
-- Bhaskar
0
K
12/24/2016 11:02:37 PM
Reply: