During replication, the binlog is replayed on the slaves,
which apply the transactions to themselves. The slaves can use different storage
engines, which makes this facility useful for ancillary purposes such as backup or
full-text indexing. Master-slave replication works well for load balancing in applications
where reads outnumber writes, since all writes must be applied to the master.
However, master-slave replication as described does not provide high availability;
there is a single master that is a single point of failure. A slave can be promoted to be
the master during failover, but the commands to do this must be executed manually
by a custom monitoring script. There is currently no facility for automatically promoting
a slave. Additionally, all clients must be able to determine which member is
currently the master. The MySQL documentation suggests setting up a dynamic
DNS entry pointing to the current master; however, this will introduce another
potential failure point.
MySQL cluster
The primary high-availability solution for MySQL is the MySQL Cluster technology,
available since version 4.1. Cluster is primarily an in-memory database, though as of
version 5, disk storage is supported. The Cluster product is based on the NDB storage
engine, backed by data nodes.
MySQL Cluster is designed for localized clusters; distributed clusters are not supported
as the protocol used between nodes is not encrypted or optimized for bandwidth
usage.
Pages:
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191