[MCOL-2153] dont allow system to start up if DBROOT 1 is not assigned to ACTIVE PARENT PM Created: 2019-02-11 Updated: 2023-10-13 Resolved: 2020-05-04 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | None |
| Affects Version/s: | 1.2.2 |
| Fix Version/s: | 1.2.6, 1.4.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | David Hill (Inactive) | Assignee: | Ben Thompson (Inactive) |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Environment: |
2um 2pm external memory |
||
| Sprint: | 2020-3, 2020-4, 2020-5, 2020-6, 2020-7 |
| Description |
|
Customer had an issue where PM1 failed and DBROOT 1 got assigned to PM2. PM2 had DBROOT 1 and 2 assigned to it and PM2 was the ACTIVE PARENT PM.. When PM1 was fixed, customer moved DBROOT 1 back to PM1, which was the incorrect process to do. DBROOT 2 should have been moved to PM1. The ACTIVE PARENT should always have DBROOT 1 assigned since it contains the DBRM files. The startsystem needs to check that DBROOT 1 is correctly assigned before allow a startsystem to run. |
| Comments |
| Comment by Ben Thompson (Inactive) [ 2020-05-01 ] |
|
I cannot manually move dbroot1 if you can find a way to do this and reproduce let me know. Otherwise I think we can close this. |
| Comment by Ben Thompson (Inactive) [ 2020-05-04 ] |
|
The state where a failed restoral leaving a PM without a dbroot assigned should no longer be reachable with failover fixes from another issue. mcsadmin also block manually moving dbroot1. |
| Comment by David Hill (Inactive) [ 2020-05-04 ] |
|
This is how they moved dbroot 1, they used the unassign and assign. That is why I opened this issue |