Timeline for Is MySQL Replication Affected by a High-Latency Interconnect?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 8, 2011 at 18:23 | history | edited | RolandoMySQLDBA | CC BY-SA 3.0 |
added 934 characters in body
|
| Aug 7, 2011 at 6:59 | comment | added | shlomoid | Yes, of course we are using MySQL 5.5, but this is not the default replication type. You need to go through a whole configuration procedure, install plugins and such, to get it working in the semi-synchronous way. | |
| Aug 7, 2011 at 3:22 | comment | added | RolandoMySQLDBA | By all means, I highly recommend using MySQL 5.5 to take advantage of this new form of MySQL Replication as well as the enhancements of InnoDB. | |
| Aug 7, 2011 at 3:18 | history | edited | RolandoMySQLDBA | CC BY-SA 3.0 |
added 5 characters in body
|
| Aug 6, 2011 at 9:01 | comment | added | shlomoid | Also, we're using the default asynchronous replication in MySQL, not the asynchronous type - which needs to be enabled on purpose by installing plugins and the likes. What I'm trying to understand is whether events are piped net-cat style into the slave from the starting position in the log, or is there back and forth exchange between the master and slave for each event, which could suffer from such latency. | |
| Aug 6, 2011 at 8:58 | comment | added | shlomoid | I am not sure about the last stage of the asynchronous replication - I don't think the master knows how far every slave has come. They can ask for any part of the binary log they want, as far as I know - do you have some reference for this? | |
| Aug 5, 2011 at 16:02 | history | answered | RolandoMySQLDBA | CC BY-SA 3.0 |