> The trouble with distributed database systems is (generally speaking) > that if you don't *really* solve *all* the synchronization problems, you > occasionally get problems. But the "problems" are "the database becomes > completely nonfunctional until you manually fix the data structures", > not "a user loses a voicemail message". > If you construct a simple, effective solution to this problem, I'm sure > that people here will want to hear about it.
And this is why I am asking questions. Most of my questions seem to be things which haven't been done or which capabilities aren't there (yet) for sipx. And that's fine but like anything else I've ever tackled, there is usually a way, even if it's not perfect, until it becomes a part of the standard system. I don't have a problem spending the time needed on this but I need input and help from those who better understand the system than I do. So on that note, in order to try some things, I need help understanding what would need to be kept in sync, which files, anything else. Then I can build two systems and start trying things. I was hoping it might be along the lines of rsync or shares files but perhaps there are other ways. Are there static files which could be shared to begin with. If yes, that's one part of the picture. The servers would have to have identical databases, which doesn't solve the VM problem yet. So, could the database part be a simple sync, restart? Or could the database be run stand alone on another server? For example, if we always put new users on the same system and that system updated the second on a regular basis, say 'copy files to temp area, shut down dbase, mv files to working dir, restart server'. That would not work if the database also has status information such as whom is currently registered but perhaps only certain files could be copied? This doesn't yet deal with VM and since I don't know about things at the file level yet, it's tough to know what else needs to happen. Seems easier to put in feature requests and use asterisk in the meantime sadly. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
