Master/Slave support? about loopback-connector-mysql HOT 12 CLOSED

I don't think this connector need to support the master-slave config.

Simply put, this connector is just an ORM. Master-slave or any high availability settings should be operation & deployment concern, not development concern.

How do you think?

from loopback-connector-mysql.

@haotangio I disagree. When developing against a high availability cluster, it is often necessary to indicate that certain queries should be against the master while allowing other queries to default to potentially lagged replicated readers. For example, if you run an update statement (which should be directed to the master of course), then attempt to read that update immediately, if replication is lagged slightly, then you will not get the updated row but instead will get the outdated row. Sequelize and many other ORM's in different languages I've used allow sending 'useMaster' as a query option in this case.

It is also useful to be able to have one or more connection pools to point to read-only hosts and another separate connection pool to point to the write host. This would enable support of several types of mysql cluster configurations.

See https://github.com/sequelize/sequelize/blob/2fc43c4cd1efe7f0ba649a7d6572119502fb0a42/lib/dialects/abstract/connection-manager.js#L239 for an example of how it is done in sequelize.

from loopback-connector-mysql.

+1

from loopback-connector-mysql.

That will be useful , but just curious, How will this Master/slave configuration be supported in your opinion? What capabilities/features are you looking for in particular from the connector? e.g. To be able to create and support master/slave configuration, connect in the failover cases and execute queries etc. seemlessly? Or allow read/write in the load balancing cases over multiple dataabse servers?

from loopback-connector-mysql.

@smartmouse the support im thinking of would be the following (in our case for the mysql connector):

1. be able to define a master connection
2. define multiple slave connections
3. have the queries default to slave for all non-mutative commands (ie. only SELECTS)
4. have mutative queries default to master (UPDATE/DELETE/INSERT)
5. support an optional param in model methods to force the query to go to either master/slave

I've noticed that the model api is very similar to sequelize. If you take a look at how sequelize handles master/slave support you'll get a good idea of what should be provided by loopback.

from loopback-connector-mysql.

@stringbeans Thanks for the info. We will do some research first and put in the backlog for offering Manager to decide/prioritize. If you come across any good ideas, please do comment here, will be more than happyt o check it out. I will definitely check out sequelize.

from loopback-connector-mysql.

thanks @jshanman i was about to reply with a similar response. there are ways around the update-read situation by using transactions, but that could just introduce unnecessary complexity.

this is perhaps a segway into another discussion but is there any reason why loopback does not just use an already available off-the-shelf ORM? that way loopback doesn't need to reinvent the wheel when it comes to an ORM for specific datasources but only maintain the juggler

from loopback-connector-mysql.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from loopback-connector-mysql.

@haotangio can you see my and @stringbeans comments and let us know if this will ever get on the roadmap?

from loopback-connector-mysql.

@jshanman I understood your idea now. Loopback should consider supporting it. Btw, I agree with @stringbeans about using currently available ORM instead of re-invent the code.

Looks like loopback team do not take care of Github issues so actively these days. A lot of issues were auto-closed.

from loopback-connector-mysql.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from loopback-connector-mysql.

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

from loopback-connector-mysql.