没有合适的资源?快使用搜索试试~ 我知道了~
高性能MySQL英文原版3
![star](https://csdnimg.cn/release/downloadcmsfe/public/img/star.98a08eaa.png)
温馨提示
![preview](https://dl-preview.csdnimg.cn/2543197/0001-8791ae74eaf3034945b968f6864c7ab9_thumbnail.jpeg)
![preview-icon](https://csdnimg.cn/release/downloadcmsfe/public/img/scale.ab9e0183.png)
试读
236页
对了解mysql的内部结构以及提高mysql服务器的性能有着非常大的帮助作用
资源推荐
资源详情
资源评论
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![mobi](https://img-home.csdnimg.cn/images/20210720083646.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![application/x-rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![thumb](https://img-home.csdnimg.cn/images/20210720083646.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![](https://csdnimg.cn/release/download_crawler_static/2543197/bg1.jpg)
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
本站提供的电子书教程均为网上搜集,如果该教程涉及或侵害到您的版权请联系我们。
![](https://csdnimg.cn/release/download_crawler_static/2543197/bg2.jpg)
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
本站提供的电子书教程均为网上搜集,如果该教程涉及或侵害到您的版权请联系我们。
![](https://csdnimg.cn/release/download_crawler_static/2543197/bg3.jpg)
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
本站提供的电子书教程均为网上搜集,如果该教程涉及或侵害到您的版权请联系我们。
![](https://csdnimg.cn/release/download_crawler_static/2543197/bg4.jpg)
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
本站提供的电子书教程均为网上搜集,如果该教程涉及或侵害到您的版权请联系我们。
![](https://csdnimg.cn/release/download_crawler_static/2543197/bg5.jpg)
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页未读,继续阅读
资源评论
![avatar-default](https://csdnimg.cn/release/downloadcmsfe/public/img/lazyLogo2.1882d7f4.png)
- my_haoxuan2018-05-17不值得下载,浪费c币
- docong2014-12-10根本不是全文,不值得下载。
![avatar](https://profile-avatar.csdnimg.cn/default.jpg!1)
hw19850907
- 粉丝: 0
- 资源: 28
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![voice](https://csdnimg.cn/release/downloadcmsfe/public/img/voice.245cc511.png)
![center-task](https://csdnimg.cn/release/downloadcmsfe/public/img/center-task.c2eda91a.png)
最新资源
- Screenshot_20240427_031602.jpg
- 网页PDF_2024年04月26日 23-46-14_QQ浏览器网页保存_QQ浏览器转格式(6).docx
- 直接插入排序,冒泡排序,直接选择排序.zip
- 在排序2的基础上,再次对快排进行优化,其次增加快排非递归,归并排序,归并排序非递归版.zip
- 实现了7种排序算法.三种复杂度排序.三种nlogn复杂度排序(堆排序,归并排序,快速排序)一种线性复杂度的排序.zip
- 冒泡排序 直接选择排序 直接插入排序 随机快速排序 归并排序 堆排序.zip
- 课设-内部排序算法比较 包括冒泡排序、直接插入排序、简单选择排序、快速排序、希尔排序、归并排序和堆排序.zip
- Python排序算法.zip
- C语言实现直接插入排序、希尔排序、选择排序、冒泡排序、堆排序、快速排序、归并排序、计数排序,并带图详解.zip
- 常用工具集参考用于图像等数据处理
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![feedback](https://img-home.csdnimg.cn/images/20220527035711.png)
![feedback](https://img-home.csdnimg.cn/images/20220527035711.png)
![feedback-tip](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![dialog-icon](https://csdnimg.cn/release/downloadcmsfe/public/img/green-success.6a4acb44.png)