Anyway, we are currently using MyISAM DB which only has table-level locking (as I just remembered). INNODB has row-level locking (but we are using MyISAM because it seems to perform better for our app).
I'll look into MySQL DB triggers. That sounds like a good avenue to explore, thanks!
---------- Post updated at 16:41 ---------- Previous update was at 16:17 ----------
According to the
MySQL 5.1 docs on triggers:
Quote:
Important
MySQL triggers are activated by SQL statements only. They are not activated by changes in views, nor by changes to tables made by APIs that do not transmit SQL statements to the MySQL Server
I assume Master-Slave replication uses SQL statements? I tried to search and have yet to find an answer. Actually, I thought replication might not use SQL statements and used some type of API mechanism. If so, the triggers on the slave based on replication updates would not work. On the other hand, if the replication mechanism uses SQL, then triggers could work.
I will keep searching for the answer; but so far no luck.
radoulov?
---------- Post updated at 16:45 ---------- Previous update was at 16:41 ----------
I think I found it !!
According to
16.1.2. Replication Formats:
Quote:
Replication works because events written to the binary log are read from the master and then processed on the slave. The events are recorded within the binary log in different formats according to the type of event. The different replication formats used correspond to the binary logging format used when the events were recorded in the master's binary log. The correlation between binary logging formats and the terms used during replication are:
*Replication capabilities in MySQL originally were based on propagation of SQL statements from master to slave. This is called statement-based replication (often abbreviated as SBR), which corresponds to the standard statement-based binary logging format. In MySQL 5.1.4 and earlier, binary logging and replication used this format exclusively.
*Row-based binary logging logs changes in individual table rows. When used with MySQL replication, this is known as row-based replication (often abbreviated as RBR). In row-based replication, the master writes events to the binary log that indicate how individual table rows are changed.
*As of MySQL 5.1.8, the server can change the binary logging format in real time according to the type of event using mixed-format logging.
When the mixed format is in effect, statement-based logging is used by default, but automatically switches to row-based logging in particular cases as described later. Replication using the mixed format is often referred to as mixed-based replication or mixed-format replication. For more information, see Section 5.2.4.3, “Mixed Binary Logging Format”.
Hmmm..... Lot's to think about here, especially since the slave is running:
Quote:
mysql Ver 14.14 Distrib 5.1.37, for debian-linux-gnu (x86_64)
16.1.2.1. Comparison of Statement-Based and Row-Based Replication