Did the fact that MySQL is open source software come into play? The openness did help us. We initially rolled out...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
our hybrid -- a mix of open horizontally scaled smaller systems and the NonStop servers -- on HP-UX machines that were field-upgradeable to [Intel] Itanium and Linux. We tried it with 64-bit HP-UX, and the current MySQL didn't support 64-bit HP-UX, so one of their programmers moved it over there. That only took a day. Once we knew how it would work with HP-UX's threading model, we incorporated that change.
MySQL doesn't have an embedded SQL pre-compiler like Oracle, Informix and DB2 have. I wrote a pre-compiler for MySQL. How did you decide to go with MySQL?
We looked at all applicable products on Unix and Linux, and we benchmarked about five different configurations on two or three hardware platforms. MySQL ran faster or as fast as any commercial database we tested. It never crashed. It was the fastest to get working, taking us two or three days to port our whole code base to it and get going.
Then, of course, MySQL saved us millions of dollars. We were quite happy to use a commercial database if it would make our core systems work. At Sabre, if you can't find the low fare or price a ticket, we can't sell a ticket to you.
Now, if you are pricing a ticket on Sabre's system, you are pricing it on C++ code on MySQL and Linux. You're not pricing it on the mainframe anymore. How has GoldenGate panned out?
Very well. We just benchmarked, and we found that GoldenGate did what we needed, and it did it reliably. We also discovered that the bottleneck in the system is not [related to] distribution but [to] our own C++ code that does the Low-Fare search. That's where 99% of the effort and heavy lifting goes. Is GoldenGate's open systems approach helpful?
GoldenGate is closed source, but it runs on many platforms. It's helped us propagate changes in real time from mainframes to NonStop to Unix to Linux. It doesn't matter what change we make anywhere in the database; GoldenGate's got a very low overhead for picking it up from a transaction log and popping it out to any number of databases in any format. We've tried moving data around to Oracle and MySQL and all sorts of databases, and it was very good. So, GoldenGate supports plenty of platforms. When we asked them to support 64-bit Linux on Itanium, they ported it very rapidly. How did you choose GoldenGate Data Synchronization Software?
Initially, we planned to build our own data distribution system. But, there are a lot of little tricks you have to do to build your own. I really didn't want to have to do that. I ran into GoldenGate [at a conference], and it looked like it would do exactly what we wanted. We chose GoldenGate because it lets us log the data in real time. We didn't evaluate other solutions, because we were on a pretty short time frame. What are your challenges today?
We're still getting our mind around how to monitor and modify 45 boxes and keep them all in lockstep. We're in good shape, but it could be a little better.
There has been no challenge with MySQL. It's been totally painless. We haven't had crashes. We haven't had anything bizarre. Linux has also proven itself very stable, and we're pleased with the performance of the Itanium processors. We've been very happy with MySQL and GoldenGate. In building our own, it could have been a lot more challenging. In this 'buy' approach, we haven't ever reached a point where we had to go back and rethink what we're doing. What's the status of your project today?
We're currently migrating the horizontal scale servers fm HP-UX (PA-RISC) to Linux (IA-64), by installing new IA-64 servers (already in place) and then field-upgrading the PA-RISC boxes (currently rp5405 hardware).
The master database runs on a cluster of HP S86000 NonStop servers, using SQL/MP (a relational database specific to NonStop). Six servers run the primary copy of the database, with six more as DR (disaster recover) and failover. We regularly perform takeover to the DR copy for OS upgrades and other maintenance functions, with zero application downtime. Fares and schedules are replicated to 45 HP rx5670 servers, each four-way Itanium 2 at 1.5 GHz, running Linux (Red Hat ES 2.1), using GoldenGate to read the transaction logs on the NonStop servers and write to MySQL. The Low-Fare search application is written in C++ and compiled with gcc 3.2.3.
We're in production today. What's your semi-final analysis of the work your team has done?
The important thing is that we're really pushing the envelope on travel technology by moving it completely off the mainframe. Nobody else is doing that. A lot of people are building front ends to the mainframe using Java or whatever, building pretty flexible user interfaces, but they're not replacing mainframes on the back end. Our largest mainframe complex is scheduled for shutdown in the next year or early 2005. We run five mainframe complexes and our largest one will be going away. We're been successful at pushing to open systems to keep our implementation costs down. It's a fairly aggressive project, and it's been successful.
FEEDBACK: Is Linux destined to slay the mainframe?
Send your feedback to the SearchEnterpriseLinux.com news team.
The No. 1 benefit is reduced cost. I can't give you exact numbers, but it's in [the] millions of dollars.
By going to C++, we measured a two-to-one programmer productivity improvement. Using better algorithms, we have access to more memory.