On Tue, 2004-04-13 at 11:21, [EMAIL PROTECTED] wrote: > Hello List: [snip] > Here is where things get sticky. I would like to be able to merge the > replicated reports into the warehouse database with the smallest practical > delay (I have some very process-driven branch mangers and they feel they > "must have" this data sooner than later). I think that I will need to hold > off merging records from any particular branch until replication completes > with that branch (to maintain relational integrity, transaction boundaries, > etc. Nobody said the reports were simple.). Somehow, I need to detect the > end of my central slaves' replication cycle so that I can trigger the > "merge processing".
Its not clear what you mean by 'replication cycle'. > I could frequently poll the slave servers using SHOW SLAVE STATUS or SHOW > PROCESS LIST and watch for their status to change. > > I could start each slave with "--log-slave-updates" and watch the slaves' > binlogs for changes. > > I could watch for the creation/deletion of the slave's relay logs. This seems to indicate that you are afraid of selecting rows on the slave that are in the middle of being updated from the master. A single update statement is still atomic, so you don't need to poll log files to determine if an update statement has finished. On the other hand, if there is some set of multiple updates and inserts that constitute a collection of data that you want to merge only when this collection is complete, you're better off finding a way to signal this through the database. You could have the master lock the tables in question until its finished and then the program quering the slave knows that when it gets a read lock, its will see the full set of data. You could also have a status column or a status table that has a flag letting the program on the slave side know when the data is ready. If this is off the mark, maybe some example statements would help... > Basically I wind up using a timer to check the status of (something) and I > am afraid that I will miss a status flip between timer ticks. Setting my > timer too short will just consume excessive CPU cycles and also be counter > productive. The target platform for my central server is tentatively Redhat > 9.x with MySQL 4.1.xxx (the stable version when we go live). Can Linux help > me here to hook into one of those events? If another OS can provide better > hooks into this I can work that into the plan. > > Can anyone tell me why these ideas would or would not work? Is there a > better way to synchronize an external process with the end of a replication > event? Are there other options I didn't think of? (I even thought of > modifying the MySQL source to produce a special "merge" slave but that will > take too many people, too much time, be too task-specific, and may not be > compatible with future versions of MySQL to be a good choice.) Please help! > > > Thanks in advance! > Shawn > [EMAIL PROTECTED] > > ** delete all the parts with "no" in them to reveal my real address. ** -- |- Garth Webb -| |- [EMAIL PROTECTED] -|
signature.asc
Description: This is a digitally signed message part
