This article discusses an issue with the Innodb auto-increment numbers used for project ID's which prevent a project from being fully removed from the system.
Symptoms
This article discusses an issue with the Innodb auto-increment numbers used for project ID's which prevent a project from being fully removed from the system.
Cause
Covered as part of the MySQL's specification as follows:
Procedure: 1. Add New Project on Web UI.(prj-A , id:2) 2. Scan prj-A, and Generate Report prj-A. 3. Delete prj-A. 4. Restart MySQL service. 5. Add New Project on Web UI.(prj-B)
a. prj-B's id was 2.(prj-A and the same) b. I could confirm prj-A's Scan status and prj-A's Report in summary screen of prj-B.
After deleting the project, the legacy data is still available in the following locations:
- records of PSE_INVENTORY_GROUPS_AUD table - records of PSE_SCHEDULER_TASKS table - /home/centos/scanroot/{PROJECT_ID_} directory - /home/centos/2018R2/reports/{PROJECT_ID_} directory - /home/centos/2018R2/proj_indexes/{PROJECT_ID_} directory
Resolution
This appears to be caused by an bug with innodb (https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html ) which prevents the correct handling of auto increment numbers. Both projects are assigned the same ID number causing multiple issues. This means that any reports generated by the deleted project are available through the new project in the UI.. A bug for this issue has been reported under reference SCA-10588 and a permanent fix for this issue is scheduled to be included in the 2018 R4 release.
