高性能MySQL英文原版3资源-CSDN文库

mysql

performance

1星需积分: 10 191 浏览量 2010-07-14 17:36:08 上传评论收藏 3.97MB PDF 举报

资源推荐

资源详情

资源评论

High Availability

449

Adding Redundancy

Adding redundancy to your system can take two forms: adding spare capacity and

duplicating components.

It’s actually quite easy to add spare capacity—you can use any of the techniques

we’ve mentioned throughout this chapter. One way to increase availability is to cre-

ate a cluster or pool of servers and add a load-balancing solution. If one server fails,

the other servers take over its load. It is generally a good idea to underutilize your

components if you can, because it gives you much more “headroom” to handle per-

formance problems caused either by increased load or by component failures.

For many purposes, you will need to duplicate components and have a standby

ready to take over if the main component fails. A duplicated component can be a

simple as a spare network card, router, or hard drive—whatever you think is most

likely to fail.

Duplicating entire MySQL servers is a little harder, because a server is useless with-

out its data. That means you must ensure that your standby servers have access to

the primary server’s data. The following sections discuss some ways you can accom-

plish this.

Shared-storage architectures

Shared storage is a way to remove some single points of failure, usually with a SAN

(see “Storage Area Networks” on page 325 for more on this). With this strategy, the

active server mounts the filesystem and operates normally. If the active server dies,

the standby server can mount the same filesystem, perform any necessary recovery

operations, and start MySQL on the failed server’s files. This process is logically no

different from fixing the failed server, except that it’s much faster because the

standby server is already booted and ready to go. Filesystem checks and InnoDB

recovery are the biggest delays you’re likely to encounter.

Shared storage helps eliminate some data loss scenarios, but it is still a single point of

failure. If it goes down, the whole system goes down. And if the failure corrupts your

data files, the standby server might not be able to recover anyway. We highly recom-

mend using InnoDB or another transactional storage engine with shared storage. A

crash will almost certainly corrupt MyISAM tables, and repairing them can take a

long time.

Replicated-disk architectures

A replicated disk is another way to keep your data safe in case of a catastrophic fail-

ure on a master server. The disk replication most commonly used for MySQL is

DRBD (http://www.drbd.org), in combination with the tools from the Linux-HA

project (more on this later).

更多电子书教程下载请登陆http://down.zzbaike.com/ebook

本站提供的电子书教程均为网上搜集，如果该教程涉及或侵害到您的版权请联系我们。

450

Chapter 9: Scaling and High Availability

DRBD is synchronous, block-level replication implemented as a Linux kernel mod-

ule. It copies every block from a primary device over a network card to another

server’s block device (the secondary device), and writes it there before committing

the block on the primary device.

DRBD runs only in active-passive mode. The passive device is a hot standby, and you

cannot access it—not even in read-only mode—unless it becomes primary. Because

writes must complete on the secondary device before the writes on the primary are

considered complete, the secondary device must perform at least as well as the pri-

mary, or it will limit write performance on the primary. Also, if you’re using DRBD

to have an interchangeable standby in the event that the primary fails, the standby

server’s hardware should match the primary server’s.

If the active server fails, you can promote the secondary device to be the primary.

Because DRBD replicates the disk at the block layer, however, the filesystem may

become inconsistent. This means it’s best to use a journaling filesystem for fast

recovery. Once recovery is complete, MySQL will probably need to run its own

recovery as well. If the first server recovers, it resyncs its device with the new pri-

mary device and assumes the secondary role.

In terms of how you actually implement failover, DRBD is similar to a SAN: you

have a hot standby machine, and you make it begin serving from the same data as

the failed machine. The biggest difference is that it is replicated storage—not shared

storage—so with DRBD you’re serving a replicated copy of the data, while with a

SAN you’re serving the same data from the same physical device as the failed

machine. In both cases, the MySQL server’s caches will be empty when you start it

on the standby machine. In contrast, a replication slave’s caches are likely to be at

least partially warmed up.

DRBD has some nice features and capabilities that can prevent problems common to

clustering software. An example is split-brain syndrome, which occurs when two

nodes promote themselves to primary simultaneously. You can configure DRBD so it

won’t let split-brain syndrome happen. However, DRBD isn’t a perfect solution for

every need. Let’s take a look at its drawbacks:

• DRBD’s failover is not subsecond. It will generally require at least five seconds to

promote the secondary device to primary, not including any necessary filesystem

and MySQL recovery.

• It’s expensive because you must run it in active-passive mode. The hot

standby server’s replicated device is not usable for any other tasks while it’s in

passive mode. Whether this is really a shortcoming depends on your point of

* You can actually adjust the level of synchronization for DRDB. You can set it to be asynchronous, to wait

until the remote device receives the data, or to block until the remote device writes the data to disk. Also, it

is strongly recommended to dedicate a network card to DRBD.

更多电子书教程下载请登陆http://down.zzbaike.com/ebook

本站提供的电子书教程均为网上搜集，如果该教程涉及或侵害到您的版权请联系我们。

High Availability

451

view. If you want truly high availability and can’t tolerate degraded service

when there’s a failure, you can’t place more than one machine’s worth of load

on any two machines, because if you did, you wouldn’t be able to handle the

load if one of them failed. You can use the standby server for something else,

such as a replication slave, but you’ll still waste some resources.

• It’s practically unusable for MyISAM tables, because they take too long to check

and repair. MyISAM is not a good choice for any installation that requires high

availability; use InnoDB or another storage engine that has good recovery perfor-

mance instead.

• It does not replace backups. If your data becomes corrupt on disk due to mali-

cious interference, mistakes, bugs, or hardware failures, DRBD will not help: the

replicated data will be a perfect copy of the corrupted original. You need back-

ups (or time-delayed MySQL replication) to protect against these problems.

Our favorite way to use DRBD is to replicate only the device that holds the binary

logs. If the active node fails, you can start a log server on the passive node and use

the recovered binary logs to bring all of the failed master’s slaves up to the latest

binary log position (see “Creating a log server” on page 374). You can then choose

one of the slaves and promote it to master, replacing the failed system.

Synchronous MySQL replication

In synchronous replication, a transaction cannot complete on the master until it

commits on one or more slave servers. There are various levels of synchronous repli-

cation, which have several common names. MySQL does not offer synchronous rep-

lication at the time of this writing, but there are third-party solutions. One such

solution is Google’s internal patches.

Google has an extensive set of patches for MySQL and InnoDB, which add many

extra features. Among them is semisynchronous replication, which causes a replica-

tion master to wait until at least one slave has received the event before it commits a

transaction. Google has released its patches for MySQL 4.0.26 and 5.0.37. You can

download the patches and several related tools at http://code.google.com/p/google-

mysql-tools.

Another option is Solid Information Technology’s high-availability technology,

which it has ported to solidDB for MySQL. This solution has several advantages over

MySQL replication, including:

• The slave cannot fall behind the master.

• Solid uses multiple threads for writing on the slave, improving replication perfor-

mance in many scenarios.

• The “safeness” level during replication is user-configurable. In 1-Safe mode,

transactions return once they are committed on the master. In 2-Safe mode,

更多电子书教程下载请登陆http://down.zzbaike.com/ebook

本站提供的电子书教程均为网上搜集，如果该教程涉及或侵害到您的版权请联系我们。

452

Chapter 9: Scaling and High Availability

transactions do not return until after they have also been committed on the

slave, providing an extra level of safety in the event of a failure.

However, it works only with the solidDB storage engine, not with MyISAM, InnoDB,

or any other storage engine. Solid may port more of its high-availability technology

for a future release.

In addition to these two variations on the MySQL server itself, you can use a middle-

ware solution such as Continuent.

Failover and Failback

Failover is the process of removing a failed server and using another server instead.

This is one of the most important parts of a high-availability architecture.

Before we go any further, let’s define a few terms. We use “failover” in a standard

way; some people use “fallback” as a synonym. Sometimes people also say “switch-

over” to denote a switch that’s planned instead of a response to a failure.

We also use the term “failback” to indicate the reverse of failover. If you have fail-

back capability, failover can be a two-way process: when server A fails and server B

replaces it, you can repair server A and fail back to it.

Failover comes in many flavors. We’ve already discussed several of them, because

load balancing and failover are similar in many ways, and the line between them is a

bit fuzzy. In general, we think a full failover solution, at a minimum, needs to be able

to monitor and automatically replace a server. This should ideally be transparent to

the application. Load balancing need not provide this capability.

In the Unix world, failover is usually accomplished with the tools provided by the

High Availability Linux project (http://linux-ha.org), which—despite their creator’s

name, run on many Unix-like operating systems. The heartbeat tool provides moni-

toring, and various other tools accomplish IP takeover and load-balancing function-

ality. You can combine them with DRBD and/or LVS.

The most important part of failover is failback. If you can’t switch back and forth

between servers at will, failover is a dead end and only postpones downtime. This is

why we like symmetrical replication topologies, such as the dual-master

configuration, and we dislike ring replication with three or more co-masters. If the

configuration is symmetrical, failover and failback are the same operation in oppo-

site directions. (It’s worth mentioning that DRBD has built-in failback capabilities.)

In some applications, it’s critical that failover and failback be as fast and atomic as

possible. Even when it’s not, it’s still a good idea not to rely on things that are out of

your control, such as DNS changes or application configuration files. Some of the

worst problems don’t show up until a system becomes larger, when issues such as

forced application restarts and the need for atomicity rear their heads. Anyone who’s

ever tried to atomically update code across many servers knows it’s difficult.

更多电子书教程下载请登陆http://down.zzbaike.com/ebook

本站提供的电子书教程均为网上搜集，如果该教程涉及或侵害到您的版权请联系我们。

High Availability

453

Because load balancing and failover are closely related, and the same piece of hard-

ware or software often serves both purposes, we suggest that any load-balancing

technique you choose provide failover capabilities as well. This is the real reason we

suggested you avoid DNS or code changes for load balancing. If you use these strate-

gies for load balancing, you’ll create extra work: you’ll have to rewrite the affected

code later when you need high availability.

The following sections discuss some common failover techniques.

Promoting a slave or switching roles

Promoting a slave to a master, or switching the active and passive roles in a master-

master replication setup, is an important part of many failover solutions for MySQL.

See “Changing Masters” on page 382 for detailed explanations of how to accom-

plish this.

Virtual IP addresses or IP takeover

You can achieve high availability by assigning a logical IP address to a MySQL

instance that you expect to perform certain services. If the MySQL instance fails, you

can move the IP address to a different MySQL server. This is essentially the same

approach we wrote about earlier, in “Moving IP addresses” on page 441, except that

now we’re using it to provide failover instead of load balancing.

The benefit of this approach is its transparency for the application. It will abort exist-

ing connections, but it doesn’t require you to change your application’s configura-

tion. It is also possible to move the IP address atomically, so all applications see the

change at the same time. This can be especially important when a server is “flap-

ping” between available and unavailable states.

The downsides are as follows:

• You need to either define all IP addresses on the same network segment, or use

network bridging.

• Changing the IP address requires root access to the system.

• Sometimes you need to update address resolution protocol (ARP) caches. Some

network devices may cache ARP entries for too long, and may not instantly

switch an IP address to a different MAC address.

• You need to make sure the network hardware supports fast IP takeover. Some

hardware requires MAC address cloning for this to work properly.

• It’s possible for a server to keep its IP address even though it’s not fully func-

tional, so you may need to physically shut it down or disconnect it from the

network.

Floating IP addresses and IP takeover work well for failover between machines that

are local to each other—that is, on the same subnet.

更多电子书教程下载请登陆http://down.zzbaike.com/ebook

本站提供的电子书教程均为网上搜集，如果该教程涉及或侵害到您的版权请联系我们。

剩余235页未读，继续阅读

评论收藏

内容反馈

my_haoxuan

2018-05-17

不值得下载，浪费c币
docong

2014-12-10

根本不是全文，不值得下载。

hw19850907

粉丝: 0
资源: 28

高性能MySQL英文原版3

高性能mysql英文版

高性能mysql英文版，

高性能mysql（第三版）

高性能MySQL

高性能MySQL-第3版-中英文版本

高性能MySQL(第3版,包含azw3,epub,mobi格式)

高性能MySQL 第3版 中英文合集 PDF

高性能MySQL(第2版)英文版

高性能mysql PDF 中英文合集

PHP和MySQL Web开发（英文原版ThirdEdition）

高可用MySQL（第2版）英文原版 MySQL High Availability, 2nd Edition

《PHP & MySQL: Novice to Ninja, 6th Edition》2017 英文原版 Kindle - mobi格式

[高性能网站建设指南——前端工程师技能精粹(英文原版)].pdf

高性能html5 高清版本（含英文原版、中文部分以及读书笔记）

高性能mysql第三版mobi和epub

mysql_tutorial （mysql简明教程，英文原版的哦）

高性能MySQL英文原版2

《PHP &amp; MySQL: Novice to Ninja, 6th Edition》- 2017 英文原版

高性能MySQL英文原版1

PHP5和MySQL圣经PHP5.and.MySQL.Bible（英文原版）

PHP Apache 和 MySQL 网页开发初步》英文原版

[英文原版] MySQL (4th Edition) (Developer's Library).pdf

PHP+MySQL八大动态Web应用实战 英文原版 清晰

PHP and MySQL Web Development英文原版

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

最新资源

高性能MySQL 第3版中英文合集 PDF

《PHP & MySQL: Novice to Ninja, 6th Edition》- 2017 英文原版

PHP+MySQL八大动态Web应用实战英文原版清晰

Qt 5实现串口调试助手（源工程文件、0积分下载）