Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
22.08.7
-
None
-
None
Description
There are number of inefficiencies that complicate S3 installation backups. One of them is the fact that save_brm utility called on cluster shutdown doesn't save oidbitmap file.
Here is a simple failure scenario that demostrates this:
1 Install MCS on S3
2 Remove all meta files in /var/lib/columnstore/storagemanager/metadata/data1/systemFiles/dbrm
3 Call mcs cluster stop or save_brm directly
In the end there will data saved on either cache or S3 + .meta files that describes EM files on S3. See the output taken after step 3.
|
[root@mcs1 dbrm]# pwd
|
/var/lib/columnstore/storagemanager/metadata/data1/systemFiles/dbrm
|
[root@mcs1 dbrm]# ls -la
|
total 32
|
drwxr-xr-x 2 root root 4096 Jan 27 03:14 .
|
drwxr-xr-x 3 root root 4096 Jan 27 02:04 ..
|
-rw-r--r-- 1 root root 247 Jan 27 03:14 BRM_saves_current.meta
|
-rw-r--r-- 1 root root 246 Jan 27 03:14 BRM_saves_em.meta
|
-rw-r--r-- 1 root root 63 Jan 27 03:14 BRM_saves_journal.meta
|
-rw-r--r-- 1 root root 244 Jan 27 03:14 BRM_saves_vbbm.meta
|
-rw-r--r-- 1 root root 241 Jan 27 03:14 BRM_saves_vss.meta
|
-rw-r--r-- 1 root root 237 Jan 27 03:14 SMTxnID.meta
|
MCS complains on its next startup about non-empty EM and lack of oidbitmap file. The suggested solution is to save oidbitmap to save oidbitmap.meta file.
Attachments
Issue Links
- is part of
-
MCOL-5403 Design a consistent snapshot backup procedure
- Open