New release of BerkeleyDB Backend Storage Engine for DURUS (20060629)
Jesus Cea
jcea en argo.es
Jue Jun 29 18:48:57 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://www.argo.es/~jcea/programacion/durus-berkeleydbstorage.htm
See the CHANGES and the UPGRADING documents.
Also updated the "KNOW_HOW-DURUS" to Durus version 3.4:
http://www.argo.es/%7Ejcea/artic/know_how-durus-3_4.htm
CHANGES:
RELEASE 20060629:
20060629 - r191 - jcea en argo.es
Document the upgrade process.
20060620 - r188 - jcea en argo.es
"get_size()" is very costly. With current implementation,
the storage must access all the database. I can implement a manual
counter or migrate to btree and use DB_RECNUM:
http://www.sleepycat.com/docs/api_c/db_stat.html
http://www.sleepycat.com/docs/api_c/db_set_flags.html#DB_RECNUM
Finally we implement a manually managed counter. Now "get_size()"
is instantaneous, but it require an storage upgrade. So, you can't
use previous backend versions.
20060620 - r184 - jcea en argo.es
When creating a new storage database, be able to
choose between "btree" and "hash" schema.
20060620 - r183 - jcea en argo.es
Document "KNOW_HOW-DURUS" updated to Durus 3.4.
20060524 - r157 - jcea en argo.es
We add a new "validate_garbage" optional parameter to the
storage constructor. If that parameter is True, the storage will
do a garbage check. Read the documentation in the README file
for details.
20060523 - r156 - jcea en argo.es
If the storage was stopped before garbage
collection was completed, the storage could leak
some unreachable objects.
Solving this issue, we make sure also that the garbage
collection makes progress even if the storage is stopped
repeatly before garbage collection completion. That is,
we store partial state to avoid to try to clean
already collected objects.
UPGRADING:
***
*** Release 20060629:
***
Storage databases created with this release are not
compatible with previous releases.
First time you use this release to open a storage
database created by previous releases, it will be
transparently "upgraded" to current format, so:
- - The storage will become incompatible with previous
releases.
- - In order to be able to upgrade the storage, you can't
open it in "read only" mode. Once upgraded, you can
use "read only" mode freely.
- - The upgrade process can be a bit slow, since the
backend needs to analyze the entire database. So, if
your database size is 1 Gigabyte and your hard disk
can push 50MB/s, the upgrade process will take about
20 seconds to finish.
- - While upgrading, the database will NOT serve requests.
- - The upgrade process doesn't take any RAM.
- - If the upgrade process is aborted (program quits, crashes,
machine reboot, etc), the database will be stable
and clean. That is, the upgrade process is transactional
and SAFE.
Also, in previous backend releases there was a bug in
the garbage collection code that would skip over
"to be deleted" objects, leaving some garbage behind.
So with this release you have three options:
- - Ignore the issue: This release will not leak new garbage,
but garbage already leaked will remain there. You lose
some diskspace. No other side effect.
- - Do a dump+load migration, using the storage backend
"migrate" method. Your diskspace requirement will
double (temporaly), since you need space for the
source and the destination databases. The migration
will copy garbage, but this new backend release can
cope with it and it will be freed. You don't need
extra RAM to do this process, even if your database
is in the petabyte range :-).
- - Initialize the storage with the "validate_garbage"
parameter sets to "True": This option will force
a full sweep over the database, to examine
cross-object links and locate garbage. This scan
is done in-place, so you don't need extra diskspace.
It is transactional, so it is SAFE if something
goes wrong.
It takes RAM proportional to object count
in your storage, so beware if you have a huge
database.
Of course you only need to pass this parameter
once, to catch garbage leaked by previous releases.
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea en argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jcea en jabber.org _/_/ _/_/ _/_/_/_/_/
_/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRKQEeZlgi5GaxT1NAQKucgP/egc+jTamJRrVEVsoACG+6PKoI/pS3W72
Xh6JCeRcLdti7unql3dYNprPTbW2aNGNmOqvWa3fxGeQL02gRUge4f2l8v+Ilwzj
Hum5yP7BtOQyLUooWyZkfvsfHcw5egKQ9+tJvFlgbZk0xN5w2qb2gskW/dqYNqd+
Y9JXZ5Ipuzo=
=B8Wy
-----END PGP SIGNATURE-----
Más información sobre la lista de distribución Python-es