On Mon, Sep 13, 2010 at 11:03 AM, Tony Graziano < [email protected]> wrote:
> As far as backup goes, I am curious if the mongodump could be invoked from > within sipxconfig backup to include this in a normal backup, though i would > be curious how mongodump would affect performance on a system and how large > the backup would be and whether this should be included automatically or be > chosen. I am also curious how these backup setting would be altered > automatically in a HA environment assuming mongodb is a master/slave, and so > the online DB would automatically "rebuild" the offline one (i.e., a basic > restore option to say, don't use the DB i have in the backup, rebuild it > from the other node because maybe it's been offline too long and I want a > fresh copy instead of making it sync back only parts, etc.). My response mentioned backups at the mongodb level would be unnec for credential and permissions. If you are saying otherwise, let me know. > As far as other operations, I could see that the export of parameters and > production of profiles and other operations could be less "system > impacting". > mongodb also replicates files as well in their gridfs, but this is considered bonus and not mentioned as part of this doc. > I would suspect that items like this... XX-8838 could be resolved with a > subset/rows for each sipxopenfire user could be made "ready" for query to > fix this issue, as an example. > XX-8838 is unrelated. Issue stems from the fact postgres is not the right tool for capturing CSEs. Could mongodb solve this too, maybe but i don't want to distract this thread from the main objective > > As far as registrations go, I could see if the DB were synced i would > wonder how the "heartbeat" or timers would function to make the failover to > the "secondary" proxy for a registered line occur in a shorter length of > time. I could see that with the right secret sauce, subscriptions and other > functions could be made to become a lot more failsafe, but that would > require a lot (tons) of framework changes. I would also want to understand > the actual "transaction" time with regard to subscriptions and registrations > as compared to postgres, but that might be hard to simulate until a fair > amount of framework had been done. > I do owe folks bytes/message calculations and whether mongodb sends all changes in bulk, or message per record. (I have to assume former, but still have to test) . The transaction time is configurable and we'd definitely want to put that into the control of the admin to pick loss of data on failover v.s. network bandwidth. > > Has thought been given to using a tunnel between systems in HA to sync > voicemail and make voicemail failover, and whether it could be an objective > achieved with the right framework and DB. There have been repeated requests > for a centralized VM system in HA, but to me thats a single point of > failure, but I could see where a pair makes sense, but if the DB was smart > enough it could "assume" the role for all users in a centralized pair if one > went down. > re:voicemail yes, this is yet another probably good use of mongodb and still a topic of another day. re:security I would like to consolidate all these different security mechanisms. Tunnels seems like a nice orthogonal way to...ok, not going there, back to the topic at hand: cred and perm dbs. > > I would just assume the ability to access the DB would be as "simple" as > postgres is? ODBC or whatever? I ask because one of the issues I see is > running CDR reports and CPU, and I'm not clear if that is the report > generator or the DB query spiking the CPU. > yes, there is a console, there might be a debugging need for looking at creds and perms on a system outside configuration database. > > I have seen a couple of issues with postgres DB in the past that could only > be overcome with a backup and restore, so even though I did a reindex and > other commands, it never resolved my issue. > > If it is not feasible to make the DB in postgres smarter to be less system > impacting, then perhaps this ought to be addressed by moving to something > else. I think the number one issue I'd have if everything else was equal or > better, was the backup/restore function of the DB and whether mongodb has > resolved a disk efficiency issue when the dump is made to the same disk, at > which point disk performance is impacted. > again, at this stage no need for backups and therefore no system impact. > > In you test document it is not noted how big the DB was in PG or MongoDB. > Can you elaborate on that? > FreeDB went from 2 to 5002 records. In mongodb i went from 5000 to 10000 records. > I know I'm all over the place with this response, but I think it's all DB > related so I wanted to comment accordingly. Even with the issues with > performance and the DB, I do find Postgres to "pretty much work", but I do > find the changes can "cripple" a system for a brief period, and that just > blows. There are major framework changes to make to add a more robust HA > system and the DB is one of those pieces. > Postgres performance may be on par with mongodb, but the replication as a first class operation in mongo is what we are really after.
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
