معرفی شرکت ها
Products.TIDStorage-5.5.0
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشترتوضیحات
TIDStorage Product provides a way to have consistent backups when running a multi-storage instance (only ZEO is supported at the moment).
| ویژگی | مقدار |
|---|---|
| سیستم عامل | OS Independent |
| نام فایل | Products.TIDStorage-5.5.0 |
| نام | Products.TIDStorage |
| نسخه کتابخانه | 5.5.0 |
| نگهدارنده | [] |
| ایمیل نگهدارنده | [] |
| نویسنده | Vincent Pelletier |
| ایمیل نویسنده | vincent@nexedi.com |
| آدرس صفحه اصلی | https://svn.erp5.org/repos/public/erp5/trunk/utils/Products.TIDStorage/ |
| آدرس اینترنتی | https://pypi.org/project/Products.TIDStorage/ |
| مجوز | - |
TIDStorage
==========
SYNOPSIS
--------
This product provides a way to have consistent backups when running a
multi-storage instance (only ZEO is supported at the moment).
Doing backups of individual Data.fs who are part of the same instance
(one mounted in another) is a problem when there are transactions involving
multiple storages: if there is a crash during transaction commit, there is no
way to tell which storage was committed and which was not (there is no TID
consistency between databases).
There is an even more tricky case. Consider the following::
2 transactions running in parallel:
T1: modifies storage A and B
T2: modifies storage A
Commit order scenario:
T1 starts committing (takes commit lock on A and B)
T2 starts committing (waits for commit lock on A)
T1 commits A (commit lock released on A)
T2 commits A (takes & releases commit lock on A)
[crash]
T1 commits B (commit lock released on B) <- never happens because of crash
Here, T2 was able to commit entirely, but it must not be saved. This is
because transactions are stored in ZODB in the order they are committed.
So is T2 is in the backup, a part of T1 will also be, and backup will be
inconsistent (T1 commit on B never happened).
TIDStorage log and server log
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TIDStorage uses two logfiles - one which is used to inform administrator
about server state (logfile_name in configuration) and TIDStorage log to which
TIDs are appended (status_file in configuration).
USAGE
-----
Put product in Zope Products to activate Zope-side patches.
Create configuration, example is provided in repozo/sample_configuration.py
Run bin/tidstorage.py with created configuration. As Zope commits transations
it will connect to TIDStorage server, which will be shown in Zope and TIDStorage
server logs.
Zope 2.12+ configuration
~~~~~~~~~~~~~~~~~~~~~~~~
Put in zope.conf section::
<product-config TIDStorage>
backend-ip ip-of-tidstorage-server
backend-port port-of-tidstorage-server
</product-config>
PYTHONPATH issues
~~~~~~~~~~~~~~~~~
To run server and scripts there is a need to set correct PYTHONPATH - at least
to product directory and for some tools to Zope lib/python.
Example:
PYTHONPATH=/usr/lib/erp5/lib/python:/usr/lib/erp5/lib/python/Products/TIDStorage
Typical scenario with failure, restoring from backup
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Zopes and Zeos running
* TIDStorage running
* backups done using repozo/repozo_tidstorage.py (they might contain
incoherency), for every backup tidstorage.tid is saved
* system failure
* restore using repozo/repozo_tidstorage.py with -t tidstorage.tid from last
backup
In this scenario only on restoration destination file is cut at point of last
known TID position. This step is optional, as in some cases administrator
might want to not cut this file.
Typical scenario with failure, no restoring needed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Zopes and Zeos running
* TIDStorage running
* system failure
* no need to restore from backup, but there might be some laying transactions
in different ZODB files, system is incoherent
* administrator use repozo/restore_tidstorage.py to cut not correctly commited
transactions, system is coherent again
TECHNICAL DETAILS
-----------------
TIDStorage fixes those issues by keeping track of transaction-to-tid relations
for all (ZODB, via ZEO) storages involved in any transaction, and by tracking
inter-transaction dependencies.
TIDStorage is composed of 3 parts:
- A Zope product, which monkey-patches "ZEO" and "transaction" products.
transaction patch
TIDStorage works at transaction boundaries, so we hook around
_commitResource method to know when it happens.
It must be configured to fit your network setup (TID_STORAGE_ADDRESS)
ZEO patch
With regular ZEO, there is no way to know last committed TID at
transaction-code level. This patch stores last committed TID on ZEO
connection object, to be read by transaction patch.
- A daemon
This is TIDStorage itself, receiving TIDs from Zopes and delivering
coherency points to backup scripts.
- Backup scripts and other utilities
Those scripts are (mostly) wrappers for repozo backup script, fetching
coherency points from TIDStorage daemon and invoking repozo.
No changes to repozo.py are needed, as it is used only as subsystem
to do reliable backups and restore.
Using provided utils in utils/ directory is it possible to query
for last known TID from server and operate on TIDStorage log.
Constraints under which TIDStorage was designed:
- Zope performance
Protocol (see below) was designed as one-way only (Zope pushes data to
TIDStorage, and does not expect an answer), so that TIDStorage speed do not
limit Zope performance.
- No added single-point-of-failure
Even if Zope cannot connect to TIDStorage, it will still work. It will only
emit one log line when connection is lost or at first attempt if it did not
succeed. When connection is established, another log line is emitted.
- Bootstrap
As TIDStorage can be started and stopped while things still happen on
ZODBs, it must be able to bootstrap its content before any backup can
happen. This is done by creating artificial Zope transactions whose only
purpose is to cause a commit to happen on each ZODB, filling TIDStorage and
making sure there is no pending commit on any storage (since all locks
could be taken by those transactions, it means that all transaction started
before that TIDStorage can receive their notification have ended).
- Restoration from Data.fs
In addition to the ability to restore from repozo-style backups, and in
order to provide greater backup frequency than repozo can offer on big
databases, TIDStorage offers the possibility to restore coherent Data.fs
from crashed ones - as long as they are not corrupted.
Limits:
- Restore "lag"
As TIDStorage can only offer a coherency point when inderdependent
transactions are all finished (committed or aborted), TIDStorage log file
backup from time T might actually contain data from moments before.
So while doing restore with -t option data will be cut to state as
time T - undefined, small lag.
There are even pathologic cases where no coherency point can be found,
so TIDStorage log file won't have any information.
Daemeon signal support:
- HUP repoens all log files
- USR1 dumps tid configuration into log file
- TERM kills daemon
PROTOCOL SPECIFICATION
----------------------
All characters allowed in data, except \n and \r (0x0A & 0x0D).
Each field ends with \n, \r is ignored.
No escaping.
When transferring a list, it is prepended by the number of included fields.
Example::
3\n
foo\n
bar\n
baz\n
When transferring a dict, it is prepended by the number of items, followed by
keys and then values. Values must be integers represented as strings.
Example::
2\n
key1\n
key2\n
1\n
2\n
Commands are case-insensitive.
1) Start of commit command:
BEGIN\n
<commit id>\n
<list of involved storages>
<commit id>: must be identical to the one given when commit finishes (be it ABORT or COMMIT)
<list of involved storages>: list of storage ids involved in the transaction
NB: final \n is part of list representation, so it's not displayed above.
Response: (nothing)
2) Transaction abort command:
ABORT\n
<commit id>\n
<commit id>: (cf. BEGIN)
Response: (nothing)
3) Transaction finalisation command:
COMMIT\n
<commit id>\n
<dict of involved storages and committed TIDs>
<commit id>: (cf. BEGIN)
involved storages: (cf. BEGIN)
committed TIDs: TIDs for each storage, as int.
NB: final \n is part of list representation, so it's not displayed above.
Response: (nothing)
4) Data read command:
DUMP\n
Response:
<dict of storages and TIDs>
5) Connection termination command:
QUIT\n
Response: (nothing, server closes connection)
6) Bootstrap status command:
BOOTSTRAPED\n
Response: 1 if bootstrap was completely done, 0 otherwise.
Change History
==============
5.5.0 (2019-06-21)
------------------
* Do not depend on Medusa HTTP server. This requires ERP5 > 2018-04-26
(commit 6d74ba22a962d08624ef35342708f333a21ceff5).
5.4.9 (2013-09-12)
------------------
* keep only the latest index files saved by recent repozo
5.4.8 (2012-07-31)
------------------
* drop base_url parameter [Romain Courteaud]
* add missing __init_.py files [Romain Courteaud]
5.4.7 (2012-07-30)
------------------
* drop circular dependency with Zope [Romain Courteaud]
* <product-config tidstorage> section is supported in zope.conf [Łukasz Nowak]
* write always pidfile, even if not forking [Łukasz Nowak]
نحوه نصب
نصب پکیج whl Products.TIDStorage-5.5.0:
pip install Products.TIDStorage-5.5.0.whl
نصب پکیج tar.gz Products.TIDStorage-5.5.0:
pip install Products.TIDStorage-5.5.0.tar.gz