question about write load distribution

[Hui Xiang]

Hi folks,

  I am reading README, and confused about below section, it said

  "If deadlock on commit cannot be tolerated by application, Galera can

still be used on a condition that all write operations to a given table are

performed on the same node. This still has an advantage over the "traditional"

master-slave replication: write load can still be distributed between nodes and

since replication is synchronous, failover is trivial."

  - What does write load can still be be distributed mean? how it differs with configuring with 3 master and having multi write loads?

  And about the quorum algorithm, I know it's based on DLV, which is the PC selector after each node finish voting? it is decided by the PC themself or is there a global selector to selct the final PC and set non PC non-primary state?

  Thanks a lot.

BR.

[Lammert Bies]

Hi Hui Xiang,

If multiple tables are written to, each table can have their own server on which they are writable. This will distribute write load over the available servers without deadlock issues. But you obviously won't have the automatic fail-over protection of a full multi-master cluster. When splitting table writes to specific servers, the system stops functioning as soon as one of the write servers fails. Fail-over for failed table writes must be handled completely at the client side adding an extra layer of complexity. The more write servers in this setup, the more likely you'll encounter such a problem. So although designating writes to specific servers may improve performance by avoiding deadlocks, the setup will be more vulnerable for server crashes than the single master multiple slave setup where you have only one point of failure.

Write server crashes in a standard Galera setup can be handled effectively at the client side with a proxy setup at a low level in the network stack which switches the complete SQL connection to another server. If table writes are distributed over multiple servers and one server stops responding, only write actions for tables handled by that server must be diverted. This needs knowledge of the actual SQL execution in the redirection of the write statements and this will probably require code at the application level, 

An extra problem may occur if you need transactions for data integrity and a transaction would involve writing to multiple tables which are served by independent servers.

Regards,

Lammert

[Hui Xiang]

Thanks Lammert.

I am asking the single master several backup setup is because people seeing problems on OpenStack if using multi-master for writes[1], but with your description, I am now more worried about single master multi backup write scenario.

"Write server crashes in a standard Galera setup can be handled effectively at the client side with a proxy setup at a low level in the network stack which switches the complete SQL connection to another server. " - Is there any such client implementation exsiting for a reference? or Can I configure something in haproxy for achieve the same goal?

[1]  https://www.percona.com/blog/2014/09/11/openstack-users-shed-light-on-percona-xtradb-cluster-deadlock-issues/

BR.

Thanks.

--
You received this message because you are subscribed to a topic in the Google Groups "codership" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/codership-team/qfHDq26U1pQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to codership-team+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lammert Bies]

I am using haproxy for client fail over.

[Hui Xiang]

Thanks Lammert.

On Mon, Jun 12, 2017 at 8:00 PM, Lammert Bies <umb...@gmail.com> wrote:

I am using haproxy for client fail over.

--