Hi Emmanuel,
I'm still having troubles during my recovery. Many thanks for your previous
reply - it gave me new direction for some further testing and I can now see
what the problem is - I just don't know the answer!
In summary it seems that only autocommited operations through Sequoia are
being written to a backend during recovery. An operation not autocommited
(say an "insert" followed by an explicit "commit") is not being written to a
backend during recovery.
Both autocomitted and explicit committed operations are being saved to the
recovery log.
Here's my new simplified test procedure to illustrate this:
Sequoia 2.10.2
1. Create new databases, start Sequoia.
2. Using "SQL Explorer" (Eclipse plugin), insert a row into the table
"tablea" - autocommit OFF, via Sequoia
insert into tablea values(122, 'abc', 122);
commit;
(see log_id 292 and 293 below)
3. Perform a backup from the Console (backup db_backup test123 PostgreSQL
<path-to-backups>)
4. Using "SQL Explorer", insert a row into the table "tablea" - autocommit
OFF, via Sequoia
insert into tablea values(133, 'abc', 133);
commit;
(see log_id 294 and 295 below)
5. Using "SQL Explorer", insert another row into the table "tablea" -
autocommit ON, via Sequoia
insert into tablea values(144, 'abc', 144);
(see log_id 296 below)
I've included the relevant rows from the recovery log:
292 | user | insert into tablea values(122, 'abc', 122)
|
| T | 289 | 290 | S | 26 |
1
293 | user | commit
|
| T | 289 | 0 | S | 0 |
0
BACKUP PERFORMED HERE.....
294 | user | insert into tablea values(133, 'abc', 133)
|
| T | 290 | 291 | S | 27 |
1
295 | user | commit
|
| T | 290 | 0 | S | 0 |
0
296 | user | insert into tablea values(144, 'abc', 144)
|
| A | 0 | 292 | S | 48 |
1
6. Perform a restore from the Console
disable *
restore backend db_primary test123 (enter backend login info...)
restore backend db_backup test123 (enter backend login info...)
enable *
7. The result is that:
"tablea" row 122 appears in the backends (both before the backup
and after the restore - as expected)
"tablea" row 133 is NOT recovered (from step 6 above)
"tablea" row 144 IS recovered (from step 6 above)
The only difference between rows (id) 133 and 144 is that 144 was
autocommitted, while 133 wasn't.
Is this a problem Emmanuel? I hope that there is enough details to help
identify the problem if there is one. Please let me know if you'd like me to
provide any further information or to perform more tests.
Looking forward to your reply,
Regards
Ken
PS:
Here is the table "tablea" after the restore...
db_primary=# select * from tablea;
id | componentname | timestamp
-----+---------------+-----------
122 | abc | 122
144 | abc | 144
(2 rows)
Here is the table "checkpoint" after the restore...
recovery=# select * from checkpoint;
name | log_id
---------------------------------------------------------+--------
Initial_empty_recovery_log | 0
backup test123-A.B.C.D:25322-20061220104027588+1030 | 293
disable db_primary-A.B.C.D:25322-20061220104651401+1030 | 296
disable db_backup-A.B.C.D:25322-20061220104651475+1030 | 296
(4 rows)
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
