This content has been marked as final. Show 5 replies
Does someone have any answer to that one?
Thanks in advance,
You are correct that you shouldn't remove internal Berkeley DB metadata files.1 person found this helpful
Internal Berkeley DB files, including our internal databases, have the prefix "__db", so you should avoid removing any of these files.
Thanks Paula for your response.
I just want to make sure: can I count on this format? I mean, Isn't that possible that internal files with a prefix other than __db will exist?
And one more question: Assuming we erase only files that are not internal files, is it eligible to remove some of the .db files, or there might be any dependencies between files so that if we erase few of them it will damage the others' functionality?
Edited by: 975807 on Dec 19, 2012 5:38 AM
I just want to make sure: can I count on this format? I mean, Isn't that possible that internal files with a prefix other than __db will exist?Your original question was about internal database files. Replication is the only part of Berkeley DB that uses internal databases. If you exclude files matching __db*.db, you will not delete our internal database files.
If you are using replication and you are planning to delete all user databases, are you planning to do so on all sites or just an individual client? Are you planning to continue replication after deleting all user databases? Why do you want to use the file system to do the deletes instead of using the Berkeley DB remove or dbremove call to remove each database?
I am less familiar with all the other internal files for all the other parts of Berkeley DB. I believe that we use the __db prefix for all of them, but I am not 100% sure. You may want to consider posting this more general question to the Berkeley DB forum:
We can make no guarantees about internal file names in future releases.
And one more question: Assuming we erase only files that are not internal files, is it eligible to remove some of the .db files, or there might be any dependencies between files so that if we erase few of them it will damage the others' functionality?If you are using Berkeley DB Replication, I would not recommend you delete a subset of your user databases using the file system. This will compromise the consistency of your replicated sites and you will have to reinitialize them from scratch. While using replication, if you want to remove individual databases you should use the Berkeley DB remove or dbremove calls to do this on your master so that these changes can be properly replicated to clients.
I am less certain of the answer if you are not using replication. I believe that there are some cases where databases do have consistency relationships with each other. For example, the Berkeley DB secondary and foreign index features require consistency between more than one database. And, of course, an application could easily have its own consistency requirements between databases. This sounds risky to me, but you may want to get another opinion on the general Berkeley DB forum.
Many thanks for the detailed answer.