Details
-
New Feature
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
None
Description
Other Ideas for different product enhancements/feature request based on customer experience.
Other Tickets:
- make periodic copies of the BRM_saves_journal - Brm_saves should keep A & B copies of the BRM_saves_journal to reduce the timeframe of dataloss and/or load_brm should attempt more auto recovery options with its own saves A & B files (MCOL 5820)
- debug utility to cleanup extent map (BRM_saves_em) - a debug utility should exist to find orphaned objects/ extent files to either delete them ( support em check script + MCOL-5781)
UPDATE: DONE
- Rebuild EM should work with S3 clusters - currently only works with single node deployments if it has access to all dbroots (meaning non-ha clusters is complicated to use or not possible)
UPDATE: WONT DO
- Rebuild EM doesnt exist in CS 5- currently only works in CS 6+ and has no official documentation
- maxscale should work with cmapi- Putting a node in maintenance mode in maxscale should work with cmapi or cmapi should notice the maintenance flag and safely remove the node from the columnstore cluster
Current Rebuild EM Notes
Internal Link: https://mariadbcorp.atlassian.net/wiki/spaces/Support/pages/1576632337/Rebuild+the+extent+map
Attachments
Issue Links
- relates to
-
MCOL-5733 Default or Automatic Extent Map Backups
-
- Needs Feedback
-
-
MCOL-5820 Enable Scheduled DBRM Backups by Default After Install
-
- Open
-
-
MCOL-5930 recovery option | mcs reset <tablelocks|BRM_saves_vbbm|BRM_saves_vss>
-
- Open
-
-
MCOL-5102 mcsRebuildEM - Triage - Failed to open compressed data file
-
- Closed
-
-
MCOL-5781 Create columnstore_repair | post dbrm restore or crash
-
- Open
-