Timeline for MySQL replication not finished on next site call
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 17, 2020 at 15:10 | comment | added | Demigod | Same here... 99% are already replicated, when they are needed. BUT if you redirect your user after writing to somewhat like a result page, you need a synchronous database. For those cases we're now encrypting the information in a new cookie which is read at the next request. That's a really quick implemented and scalable behaviour. | |
| Feb 12, 2020 at 18:19 | comment | added | jynus | I don't disagree about the complexity, but I am curious why you think the second part of your comment? A 1-second lag will create around the same async issues than a 30 second one, there are points in which you need sync reads anyway. In fact, in our case, we are 99% on 0-1 seconds range as transactions larger than 1 second are killed automatically. | |
| Feb 11, 2020 at 19:17 | comment | added | Rick James | Thanks for the link about "chronology protector". It seems somewhat complex, and perhaps more aimed at a site which expects 30-second lags as opposed to 1-second lags. | |
| Feb 7, 2020 at 14:35 | comment | added | Demigod | MASTER_POS_WAIT works perfect! Thanks for the answer. I wouldn't have figured this out alone. | |
| Feb 7, 2020 at 14:34 | vote | accept | Demigod | ||
| Feb 7, 2020 at 12:00 | history | answered | jynus | CC BY-SA 4.0 |