Quantcast
Channel: StackExchange Replication Questions
Viewing all articles
Browse latest Browse all 17268

Best approach for archiving transactional data in MySQL 5.5

$
0
0

I'm new to MySQL. I'm looking into setting up a MySQL 5.5 instance on Amazon's RDS. I have worked with DB2 in the past as a developer, but not as a DBA.

I have a requirement to store transactional (not in the normal sense, read on :^) ) data in the database. When I did this on DB2, we used CCD tables to accomplish this. The CCD setup basically used an external job that parsed the log files, then loaded the transactions into tables that mirrored the original tables, plus contained additional columns for the transaction metadata (when did the transaction occur, was it an Insert/Update/Delete, etc). Some of the "how" may be a little off, but the end effect is accurate.

That approach was nice, because it added no risk to the actual transactions themselves and rollbacks were handled nicely as well. I need to accomplish the same thing, but using MySQL.

Possible Approach

In MySQL, I could accomplish this by creating separate triggers on each table I want to capture transactions on, for each type of transaction (I/U/D), and have the triggers populate some new tables I create to mirror the original tables I want to monitor.

I've written plenty of database triggers in the past, so this approach seems doable. However, this seems like a heavy handed hack with potential performance penalties and added risk to each transaction and will likely run into other unforeseen MySQL newb type issues. Is there another more, MySQL style, approach for handling this? The data doesn't need to remain in the same database and preferably would be stored in a separate database.


Viewing all articles
Browse latest Browse all 17268

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>