Feature #55157
closed
Support for MySQL replication
0%
Description
I made a setup which runs on two different hosts, with a MySQL master (A) and slave (B) replication. However, there is IMHO a lot of optimization potential.
The main problem occurs when visiting the page on B. As TYPO3 wants to write data to e.g fe_session_data or index_*, the slave will lock up on the next few transactions because of a duplicate primary key error. However, setting B's mysql to read only will result in failed queries.
Related: http://forge.typo3.org/issues/17088
I am not sure if that would generally help, but maybe an option in the install tool to set the TYPO3 instance to a "slave" mode would trigger a switch in the persistence layer to not execute INSERT and UPDATE statements on the slave. Of course, this would be extension- and setup-dependent, because you can't e.g. edit your fe_user profile on the slave then.
I just wanted to "braindump" this here, maybe it results in a constructive discussion and an enhancement to TYPO3, or it gets ignored or buried.
Files
Updated by Thomas Löffler over 10 years ago
We are using a workaround for a slave DB.
I would put a change into Gerrit.
Who has the possibility to test it?
Updated by Thorsten Kahler over 10 years ago
Thomas Loeffler wrote:
We are using a workaround for a slave DB.
I would put a change into Gerrit.
Would you mind to describe your workaround here? It might help to discuss your approach before discussing your code...
Updated by Thorsten Kahler over 10 years ago
- Status changed from New to Needs Feedback
Updated by Thomas Löffler over 10 years ago
- File slave.diff slave.diff added
We have this workaround.
Updated by Alexander Opitz over 10 years ago
- Status changed from Needs Feedback to New
Updated by Christian Kuhn almost 10 years ago
- Status changed from New to Closed
Yeah.
For the time being, there is no core API that can send "reading" queries to a different connection pool that "writing" queries.
This would require a major change and can not be easily solved in one issue, since it should then handle even more scenarios. A relatively clean solution at the moment would be a db query dispatcher as 3rd party proxy between typo3 and db, a hacky solution is shown by thomas with his patch.
This issue here will be reset to "rejected" for now. This general issue here does not help us much at the moment.
If anyone would like to work in this area, it would be great to get it touch with some of the DB related interested people within the community to think about the bigger plan and to create / modify an according blueprint for this in the first place.