Well thank you Ron for this information as I'm not really familiar whith replacating databases. But the single hosted solution is something my bosses don't want at all. Our internet connection in our headquarters is reliable and redundant so that wouldn't be the problem. But what pretty often occurs is that one of our other locations are loosing there internet connectivity. As you might know it is hard to get redundancy at a payable price in some places of the world. But the location should still be able to use OTRS when there line is down as they would need it for the daily work. So any other ideas out there besides hosting a single system.
-----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Ron DeFulio Gesendet: Donnerstag, 23. August 2007 16:27 An: 'User questions and discussions about OTRS.org' Betreff: RE: [otrs] Database replication Thorsten, I think you need to reconsider your argument for master-master replication. First, if you've got a "real slow connection" between the sites, your replication is going to be hopelessly backlogged. Viewing HTML of a single ticket is -far less data- than replicating every change made into every table from every site. Further, if the internet connection is down -forget about replication- because when mysql becomes desynched it basically does a full resync which takes HOURS on a full speed line. I have experience with mysql one-way replication and this is tedious on its own. We experimented with master-master replication on dedicated t1 lines and we had so many problems that we changed our model to a single-master and used the replicated nodes as read-only nodes (queueing the updates back to the master with a special api). If your headquarters does not have a reliable internet connection, you should consider hosting the application with an ISP that guarantees uptime. If your branch locations are without internet, they are going to be down anyway. With no connectivity to the other master databases you're going to have unresolvable synch issues where two people change the same ticket -- whose data is correct? You are expecting the OTRS application to "just work" in a master-master situation across slow or disconnected lines, let me assure you, if the OTRS programmers havent specifically built the software to work master-master in this situation, you're going to find that it screws up constantly. Take the issue of creating a new record number. Typically this process, which is what links all related tables and records together, needs to have a guaranteed unique number across the board. Without a connection, a disconnected master doesn't know what numbers have been used up. If two "record 1000's" are created in a master-master situation, you've got an unresolvable conflict. You would have to uniquely identify every site with a unique prefix, and then only allocate numbers with those prefixes. This logic would need to apply to every table where records can be added.. Users/groups/tickets/followups/customers... Practically every table. This is not "typical" design requirement. Finally, as far as intranet/extranet this is a non-issue. You secure the site at the ISP with a private cert and install a client cert onto every branch-office computer that allows them to access the site. It secures the connection and prevents access outside the company without being issued a client cert. Master-master replication is not a magic bullet to fix problems. It's a very complex environment that is useful in specific cases where the need for master-master outweighs the downsides of its implementations. Your requirements and your situation screams out for a single hosted application at a secure location shared by your branch locations. In the case of an outage, cellular wifi internet will cut it for the simple html pages served up by OTRS. I have experience doing master-master replication back in the dos days before mysql. We wrote our own software to replicate changes across a 56k dedicated line between New York and California. There is a lot behind making master-master work with any level of reliability. Its imperitive to never lose a customer's data because of replication overwrites or conflicts. This is difficult stuff to do and requires a level of granularity not typical for every-day applications. Microsoft Active Directory, for example, manages master-master replication because every field in every record is timestamped and clocks are guaranteed to be synched across the domain. Microsoft uses a special technique of generating a GUID that is unique to a particular object so there are no conflicts. These are concepts just outside the scope of OTRS and how it was intended to be used. Again you are assuming these issues will just magically resolve themselves by turning on master-master replication in MYSQL or PostgreSQL and I think you'll find this is just not the case. Good luck with your endeavor, Ron -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 23, 2007 9:29 AM To: [email protected] Subject: AW: [otrs] Database replication Well what I try to accomplish is that every location has access to the same datasource to share information about the solutions. The main problem is that not all of our location are on the same network. And I really don't want to place the OTRS-System in the DMZ because we want to use it as an internal helpdesk tool. So yes we want to have an installation on every site but with the same (replicated) Database. We need to have the database on every location as some of them have a real slow connection to our headquarter. And my colleagues around the world should still be able to work with the system if there internet connection is down. But I will try it with the master-master replication and see if this will do for us. Regards Thorsten -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Peter van Beugen Gesendet: Mittwoch, 22. August 2007 22:35 An: User questions and discussions about OTRS.org Betreff: RE: [otrs] Database replication I use MySQL (5.0.x) master-slave replication and it does a great job. But I use the slave as a backup server. MySQL 5.1 even promises better replication. check: http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html But I do not understand what you want to accomplish with replicated databases as OTRS is pure browser based. IMHO: put the webserver very close to the database server and you will have the best performance. Or are you going tu use multiple distributed webservers? regards, Peter van Beugen -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] namens [EMAIL PROTECTED] Verzonden: wo 22-8-2007 19:06 Aan: [email protected] Onderwerp: [otrs] Database replication Hi, i'm working for an international operating company and we want to use otrs as our global helpdesk-system. So I need a way to replicate the databases to different location so that every location has the same view, or at least almost. Has anybody done this before and give me a little hint how to accomplish this. Many thanks in Advance Thorsten _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? =http://www.otrs.com/ _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? =http://www.otrs.com/ _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/
