Topic: Sending of certainly not clashing updates on group
TL; DR: the question is selected fat more low. There is such task: there is some service with several nodami-hosts. Each of can receive some task on handling and on the handling termination should send update to remaining hosts about result of handling in such a manner that all hosts as a result should have an information under the processed tasks. These updates certainly do not clash with each other so even if the task is processed some times, it is possible to specify any host which it processed. It would be desirable to have possibility to read the status under any processed task from any host through time t after handling of this specific target, we consider that it is possible to influence requirements and to make t big enough, for example some hours. While the task in handling it is possible to consider that those who is interested in the intermediate status of handling can read it directly from a host conducting handling. Decisions which look obvious: 1. The Database. It would not be desirable to take, as information under tasks it is insignificant a little (at the most optimistical forecasts of usage it will not be typed more than 100 Gb for ~5 years). As it would be desirable to make API on reading of the status of the task as far as possible fast - and a DB here as though approaches it is possible answers under old tasks, on the other hand if it would be possible and to make its persistent it would solve the task. 2. + + to copy a local DB  from a host on a host. It seems most close to that is necessary. Not clearly how to make so that queue did not delete the message while all hosts do not read the message in this queue. While I tend to the most simple "classical" decision - a separate DB with several for sufficient stability of type of Oracle RAC, but it would be interesting to learn - whether there is a simple decision allowing simply and reliably such certainly not clashing updates from a local DB  on group of hosts? The samopisnoe decision looks at first sight simply - to pull all hosts on end of the task enough and to deliver them update. But if to take into consideration that (1) hosts can be much, (2) network and hosts can periodically , (3) operation of transmission of update can be broken off in the middle because pulled out a cord of a supply and a server stand was suddenly disconnected (so it is necessary to add decisions on sending of updates where that in file system) this decision any more does not look simple. - -  such as for example Berkeley DB and with it.