Drivers¶
Tooz is provided with several drivers implementing the provided coordination API. While all drivers provides the same set of features with respect to the API, some of them have different properties:
- zookeeper is the reference implementation and provides the most solid features as it’s possible to build a cluster of ZooKeeper that is resilient towards network partitions for example.
- memcached is a basic implementation and provides little resiliency, though it’s much simpler to setup. A lot of the features provided in tooz are based on timeout (heartbeats, locks, etc) so are less resilient than other backends.
- `redis`_ is a basic implementation and provides reasonable resiliency when used with redis-sentinel. A lot of the features provided in tooz are based on timeout (heartbeats, locks, etc) so are less resilient than other backends.
- ipc is based on Posix IPC and only implements a lock mechanism for now, and some basic group primitives (with huge limitations). The lock can only be distributed locally to a computer processes.
- file is based on file and only implements a lock based on POSIX or Window file locking for now. The lock can only be distributed locally to a computer processes.
- zake is a driver using a fake implementation of ZooKeeper and can be used to use Tooz in your unit tests suite for example.
- `postgresql`_ is a driver providing only distributed lock (for now) and based on the PostgreSQL database server.
- `mysql`_ is a driver providing only distributed lock (for now) and based on the MySQL database server.
Backends¶
file¶
A file based driver.
This driver uses files and directories (and associated file locks) to provide the coordination driver semantics and required API(s). It is missing some functionality but in the future these not implemented API(s) will be filled in.
NOTE(harlowja): it does not automatically delete members from groups of processes that have died, manual cleanup will be needed for those types of failures.
ipc¶
A IPC based driver.
This driver uses IPC concepts to provide the coordination driver semantics and required API(s). It is missing some functionality but in the future these not implemented API(s) will be filled in.
kazoo¶
This driver uses the kazoo client against real zookeeper servers.
It is fully functional and implements all of the coordination driver API(s). It stores data into zookeeper using znodes and msgpack encoded values.
memcached¶
A memcached based driver.
This driver users memcached concepts to provide the coordination driver semantics and required API(s). It is fully functional and implements all of the coordination driver API(s). It stores data into memcache using expiries and msgpack encoded values.
mysql¶
A `MySQL`_ based driver.
This driver users `MySQL`_ database tables to provide the coordination driver semantics and required API(s). It is missing some functionality but in the future these not implemented API(s) will be filled in.
postgresql¶
A `PostgreSQL`_ based driver.
This driver users `PostgreSQL`_ database tables to provide the coordination driver semantics and required API(s). It is missing some functionality but in the future these not implemented API(s) will be filled in.
redis¶
Redis provides a few nice benefits that act as a poormans zookeeper.
It is fully functional and implements all of the coordination driver API(s). It stores data into `redis`_ using the provided `redis`_ API(s) using msgpack encoded values as needed.
- Durability (when setup with AOF mode).
- Consistent, note that this is still restricted to only one redis server, without the recently released redis (alpha) clustering > 1 server will not be consistent when partitions or failures occur (even redis clustering docs state it is not a fully AP or CP solution, which means even with it there will still be potential inconsistencies).
- Master/slave failover (when setup with redis sentinel), giving some notion of HA (values can be lost when a failover transition occurs).
To use a sentinel the connection URI must point to the sentinel server. At connection time the sentinel will be asked for the current IP and port of the master and then connect there. The connection URI for sentinel should be written as follows:
redis://<sentinel host>:<sentinel port>?sentinel=<master name>
Additional sentinel hosts are listed with multiple sentinel_fallback
parameters as follows:
redis://<sentinel host>:<sentinel port>?sentinel=<master name>&
sentinel_fallback=<other sentinel host>:<sentinel port>&
sentinel_fallback=<other sentinel host>:<sentinel port>&
sentinel_fallback=<other sentinel host>:<sentinel port>
Further resources/links:
Note that this client will itself retry on transaction failure (when they keys being watched have changed underneath the current transaction). Currently the number of attempts that are tried is infinite (this might be addressed in https://github.com/andymccurdy/redis-py/issues/566 when that gets worked on). See http://redis.io/topics/transactions for more information on this topic.