error after copying RAM repository to more recent RAM server: The persist folder is not synchronized with the database
We are intending to move a RAM repository from one RAM instance to another. We opted to do this by copying the persist file system and the RAM and RTC databases, rather than exporting metadata and assets 1000 at a time.
We encountered the following error on starting the new server after having copied the persist fs and db:
The persist folder has never been synchronized with any database, but the database indicates it has done a synchronization in the past. This could be because the persist folder is an older backup from before the migration or is for another repository that has not yet been migrated to the new format.
The persist folder is not synchronized with the database. A message above explains the problem. You can force the persist folder to be marked as synchronized. This will only marked it as synchronized. It will not change any data. Depending on how far off the data is from the database there could be problems accessing certain files since they may not be there or they may be older or newer than the database.
(We're seeking answers to three questions, marked Q1-3 below.)
We are speculating that the error may arise from the fact that the destination database is from a more recent release than the source database: This could be because the persist folder is...for another repository that has not yet been migrated to the new format
(Q1) Is this specualtion correct? This seems a little improbable, considering that both the db content and fs are from the source server.
As an alternative explanation we're considering whether the error may arise from omitting part of the persist fs, the part that marks it as synchronized:
The persist folder has never been synchronized with any database, but the database indicates it has done a synchronization in the past... You can force the persist folder to be marked as synchronized. This will only mark it as synchronized.
Both the folder and the db should be from the old repository and so both should indicate they have been synched or both should not...
(Q2) So how is the persist folder marked as synchronized? Is there a metadata/properties file that could have been omitted?
(Q3) Should we "force the persist folder to be marked as synchronized", or should we modify the procedure we are using to copy the server?
Any information/background on the source of the error would be appreciated.
Details of our procedure follow:
|
Accepted answer
One other answer
Database, wold be the things that will instigate a migration ... but the DB should always be on the same level as the persist.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
1) The databases and persist folders must be backed up and at the same time (and RAM and RTC should of been down during the backup) and then those used to restore to a new location. 2) This error indicates that you didn't get the files in the root of the persist folder when you moved. The persist folder is everything under the com.ibm.ram.persist subfolder. You must copy the entire com.ibm.ram.persist folder as is and put it in the new location and point the persist directory in server setup to be the folder that "contains" the com.ibm.ram.persist subfolder that you copied. In that subfolder there must be two files (persist.properties and persistS.txt) plus the bucket-x folders.
Are you sure you restored the source RAM database into the new RAM destination's database?
This is looking to me like the new ram instance is still seeing the contents of the initial new ram instance database that you created in step (1). If that is the case then what is happening is RAM is looking at the intermediate 7511 that HAD a persist control file in the persist area (so it is indicated in the database) but it is looking at your updated persist folder from old RAM. 751 RAM did not have a persist sync control file. That was added in 7511.
I think you're onto it... what happened is that our cloud vendor initially brought the server up with the 751 db's but the 7511 persist; after realizing the situation, he swapped in the 751 persist, and we got the synch error. I'll update the thread when we do our final dry run, my hope and expectation is that when done correctly we will not see the error again.
Thanks for the info about the persist sync control file in 7511, that was part of my original question that I was particularly interested in to hear the answer.