GeoMapX

Для обеспечения высокой доступности при минимальной нагрузке оптимальным решением является синхронизация учетных записей пользователей из основной БД в базу ejabberd (mnesia). Ранее я приводил пример авторизации внешним скриптом, но для более-менее серьезного применения это создает лишнюю нагрузку на основную БД, плюс снижает доступность. См. ejabberdctl should be able to dump to stdout . Дамп пользователей sudo ejabberdctl dump_table /tmp/dump passwd Парсер дампа #!/usr/bin/tclsh8.5 proc K {arg args} {set arg} proc В результате для каждого виртуального хоста получаем список формата {nickname password}, далее сравниваем с аналогичной записью в основной БД и для отличающихся обновляем через ejabberdctl или любым удобным нам способом. Скрипт разумно запускать от имени пользователя ejabberd, подкладывая ему в заранее определенное место дамп пользователей из основной базы или настроив доступ на чтение к основной базе. Дамп 3000 пользователей из ejabberd занимает около 0,25 с, обно...

Предупреждение: написано в стиле заметок на полях и воспроизводит ход размышлений автора, у читателей процесс размышления, равно как и наличие этого самого процесса и его результаты, могут отличаться! Посещавшие меня мысли о распределенных базах данных и их применимости начинают обретать законченные черты, а значит, самое время сделать соответствующую реализацию. Поскольку я уже знаю ответ на вопросы "что, как, зачем", то можно погуглить для ознакомления с уже существующими реализациями и лежащими в их основе концепциями. Основная идея состоит в том, что распределенная БД отнюдь не предполагает и не требует распределенную СУБД. Посмотрим на это утверждение с такой стороны - информация первична, а способ ее представления - вторичен. Например, из споры можно "восстановить" бактерию, а бактерии вовсе незачем раздуваться до размеров материка, когда можно просто превратить себя в спору и с попутным ветром этот материк перелететь, после чего "ожить". А дальш...

The new version of sqlite3-rdiff utility can produce really small signatures. See below test on 10 Mb database. The analyze mode will help you to select optimal parameters for your databases.

Depends: current test version of sqlite3-rdiff The sqlite3-rdiff utility produces a signature file of size about 10% of original database size. Yes, it's better than coping an entire database but it's not good enough for production use. So I wrote a new algorithm that can build the small signatures. The algorithm calculates checksums for set of rows and so with N rows in each set the signature size will be decreased by the factor of N! Of course the delta file size will be increased but only a little for most databases. My code uses a hack select rowid/N as rowid, sum(murmurhash('$unixepoch',$cols)) from ... group by rowid This solution is not good and may be used for testing only. This code will fail with N>16. $ time ./sqlite3-rdiff signature slave.db slave.db.signature signature slave.db slave.db.signature --table-name % --rows-per-hash 1 =7 system_config =160 center =7 role =1 macroregion =988 point =7 region =1841 user =2867166 document_status =25 c...

Link: http://mobigroup.ru/files/sqlite-ext/sqlite3-rdiff Depends: tcl 8.5, sqlite3, murmurhash SQLite extension I'm glad to annonce the sqlite3-diff utility for SQLite replication. Are used the ROWID value as unique key of row and murmurhash for build signatures for each row. It's enough for master-slave replication. The INTEGER PRIMARY KEY is not mandatory becouse sqlite3-rdiff may store the ROWID values. The signature and delta files are valid SQLite3 databases too. They can be dumped/restored, updated and analyzed by any SQLite3 client application. Hash collisions are resolved by using unique salt for each signature. So after first sync the theoretical frequency of collision (when any record is changed but the hash is same) is about 10^-9, after second sync - 10^-18, after N syncs - 10^-N*9. The salt is unix epoch time which is saved by using "PRAGMA user_version" in signature and delta databases. Note: the master-master replication is now unsupported becouse is...

Нежданно-негаданно встретилась ссылка на следующий проект: rubyrep - репликация для PostgreSQL и MySQL. Непосредственно реализацию не смотрел, а вот дизайн системы мне понравился. А вот насчет master-master режима есть разумное сомнение - разработчики предлагают некоторые алгоритмы разрешения конфликтов, но, по сути, если архитектура реплицируемой базы позволяет возникновение конфликтов, это проблема архитектуры, а отнюдь не репликатора. Вместо того, чтобы изменять одну и ту же таблицу на разных хостах, можно создать набор схем (schema) так, что каждый хост работает со своей схемой, тогда при репликации каждый хост будет мастером для "своей" схемы и слэйвом для "чужих". В эскулайте то же самое реализуется созданием набора баз данных (притом часть идентификаторов должны иметь или сквозную нумерацию, или быть уникальными uuid).

For some reasons may be useful online replication from PostgreSQL database to SQLite database or databases. I write this as set of pltclu procedures for my PostgreSQL database like to CREATE OR REPLACE FUNCTION document_status_sqlite3() RETURNS "trigger" AS $BODY$ set t1 [clock clicks] load /usr/share/tcltk/tcl8.5/sqlite3/libtclsqlite3.so sqlite3 set db_file /var/www/project_name/res/dataset/work.db sqlite3 db $db_file db timeout 4000 # db eval {PRAGMA journal_mode = PERSIST} if { $TG_op eq "INSERT" } { set save_date [string range $NEW(save_date) 0 18] db eval {insert into document_status (save_date,document_id, user_id,value, is_last,is_last_status,is_first) values (julianday($save_date,'-3 hour'),$NEW(document_id), $NEW(user_id),$NEW(value), case when $NEW(is_last)='t' then 1 else 0 end, case when $NEW(is_last_status)='t' then 1 e...