Before today, we have not had good luck releasing schema changes to our environment without affecting our GoldenGate replication topology adversely. All ill effects have been surmountable, but stressful, nonetheless. We have a Hot, Warm and DR set of servers that has GoldenGate sending the data from Hot to Warm and Hot to DR. Most of the data is replicated in this fashion, and its fast. We have very little latency, compared to Native Replication we have used in the past.
But doing a release has always been a scary proposition. We would turn things back on, only to have massive errors, and time spent fixing the errors. We have tested and tested and performed more tests to ensure that we have a plan of attack that will succeed.
Today was the day! It all paid off!! We now have a process that allows us to block a table, perform a schema change to it, and through appropriate steps, stop and restart replication where needed. Many steps are needed to perform this, and in this case, it was a two man job to perform the release. The bulk was done in about 14 minutes, with us taking our time, being cautious, and validating our changes. The rest of the release proceeded as a simple release should, and went off without a hitch.
This is a happy day. We have a successful release plan to update schema on live tables, being replicated with GoldenGate replication, without bring it down upon our heads. Yeah.
2 comments:
What testing did you guys do before putting Golden Gate in production? We recently purchased GG. Any gotchas we need to be aware of?.
Thanks
I was not around when it was tested and pushed to production. One of the big issues we now have is DDL changes. These have to be dealt with very carefully.
We have seen that GoldenGate replication is a lot faster and less likely to go latent than Native.
Post a Comment