少年阿賓

Linux is a powerhouse when it comes to networking, and provides a full featured and high performance network stack. When combined with web front-ends such asHAProxy, lighttpd, Nginx, Apache or your favorite application server, Linux is a killer platform for hosting web applications. Keeping these applications up and operational can sometimes be a challenge, especially in this age of horizontally scaled infrastructure and commodity hardware. But don't fret, since there are a number of technologies that can assist with making your applications and network infrastructure fault tolerant.

One of these technologies, keepalived, provides interface failover and the ability to perform application-layer health checks. When these capabilities are combined with the Linux Virtual Server (LVS) project, a fault in an application will be detected by keepalived, and the virtual interfaces that are accessed by clients can be migrated to another available node. This article will provide an introduction to keepalived, and will show how to configure interface failover between two or more nodes. Additionally, the article will show how to debug problems with keepalived and VRRP.

What Is Keepalived?

---

The keepalived project provides a keepalive facility for Linux servers. This keepalive facility consists of a VRRP implementation to manage virtual routers (aka virtual interfaces), and a health check facility to determine if a service (web server, samba server, etc.) is up and operational. If a service fails a configurable number of health checks, keepalived will fail a virtual router over to a secondary node. While useful in its own right, keepalived really shines when combined with the Linux Virtual Server project. This article will focus on keepalived, and a future article will show how to integrate the two to create a fault tolerant load-balancer.

Installing KeepAlived From Source Code

---

Before we dive into configuring keepalived, we need to install it. Keepalived is distributed as source code, and is available in several package repositories. To install from source code, you can execute wget or curl to retrieve the source, and then run "configure", "make" and "make install" compile and install the software:

$ wget http://www.keepalived.org/software/keepalived-1.1.17.tar.gz  $ tar xfvz keepalived-1.1.17.tar.gz   $ cd keepalived-1.1.17  $ ./configure --prefix=/usr/local  $ make && make install 

In the example above, the keepalived daemon will be compiled and installed as /usr/local/sbin/keepalived.

Configuring KeepAlived

---

The keepalived daemon is configured through a text configuration file, typically named keepalived.conf. This file contains one or more configuration stanzas, which control notification settings, the virtual interfaces to manage, and the health checks to use to test the services that rely on the virtual interfaces. Here is a sample annotated configuration that defines two virtual IP addresses to manage, and the individuals to contact when a state transition or fault occurs:

# Define global configuration directives global_defs {     # Send an e-mail to each of the following     # addresses when a failure occurs    notification_email {        matty@prefetch.net        operations@prefetch.net    }    # The address to use in the From: header    notification_email_from root@VRRP-director1.prefetch.net     # The SMTP server to route mail through    smtp_server mail.prefetch.net     # How long to wait for the mail server to respond    smtp_connect_timeout 30     # A descriptive name describing the router    router_id VRRP-director1 }  # Create a VRRP instance  VRRP_instance VRRP_ROUTER1 {      # The initial state to transition to. This option isn't     # really all that valuable, since an election will occur     # and the host with the highest priority will become     # the master. The priority is controlled with the priority     # configuration directive.     state MASTER      # The interface keepalived will manage     interface br0      # The virtual router id number to assign the routers to     virtual_router_id 100      # The priority to assign to this device. This controls     # who will become the MASTER and BACKUP for a given     # VRRP instance.     priority 100      # How many seconds to wait until a gratuitous arp is sent     garp_master_delay 2      # How often to send out VRRP advertisements     advert_int 1      # Execute a notification script when a host transitions to     # MASTER or BACKUP, or when a fault occurs. The arguments     # passed to the script are:     #  $1 - "GROUP"|"INSTANCE"     #  $2 = name of group or instance     #  $3 = target state of transition     # Sample: VRRP-notification.sh VRRP_ROUTER1 BACKUP 100     notify "/usr/local/bin/VRRP-notification.sh"      # Send an SMTP alert during a state transition     smtp_alert      # Authenticate the remote endpoints via a simple      # username/password combination     authentication {         auth_type PASS         auth_pass 192837465     }     # The virtual IP addresses to float between nodes. The     # label statement can be used to bring an interface      # online to represent the virtual IP.     virtual_ipaddress {         192.168.1.100 label br0:100         192.168.1.101 label br0:101     } } 

The configuration file listed above is self explanatory, so I won't go over each directive in detail. I will point out a couple of items:

• Each host is referred to as a director in the documentation, and each director can be responsible for one or more VRRP instances
• Each director will need its own copy of the configuration file, and the router_id, priority, etc. should be adjusted to reflect the nodes name and priority relative to other nodes
• To force a specific node to master a virtual address, make sure the director's priority is higher than the other virtual routers
• If you have multiple VRRP instances that need to failover together, you will need to add each instance to a VRRP_sync_group
• The notification script can be used to generate custom syslog messages, or to invoke some custom logic (e.g., restart an app) when a state transition or fault occurs
• The keepalived package comes with numerous configuration examples, which show how to configure numerous aspects of the server

Starting Keepalived

---

Keepalived can be executed from an RC script, or started from the command line. The following example will start keepalived using the configuration file /usr/local/etc/keepalived.conf:

$ keepalived -f /usr/local/etc/keepalived.conf 

If you need to debug keepalived issues, you can run the daemon with the "--dont-fork", "--log-console" and "--log-detail" options:

$ keepalived -f /usr/local/etc/keepalived.conf --dont-fork --log-console --log-detail 

These options will stop keepalived from fork'ing, and will provide additional logging data. Using these options is especially useful when you are testing out new configuration directives, or debugging an issue with an existing configuration file.

Locating The Router That is Managing A Virtual IP

---

To see which director is currently the master for a given virtual interface, you can check the output from the ip utility:

VRRP-director1$ ip addr list br0 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN      link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff     inet 192.168.1.6/24 brd 192.168.1.255 scope global br0     inet 192.168.1.100/32 scope global br0:100     inet 192.168.1.101/32 scope global br0:101     inet6 fe80::224:8cff:fe4e:7f6/64 scope link         valid_lft forever preferred_lft forever  VRRP-director2$ ip addr list br0 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN      link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff     inet 192.168.1.7/24 brd 192.168.1.255 scope global br0     inet6 fe80::224:8cff:fe4e:7f6/64 scope link         valid_lft forever preferred_lft forever 

In the output above, we can see that the virtual interfaces 192.168.1.100 and 192.168.1.101 are currently active on VRRP-director1.

Troubleshooting Keepalived And VRRP

---

The keepalived daemon will log to syslog by default. Log entries will range from entries that show when the keepalive daemon started, to entries that show state transitions. Here are a few sample entries that show keepalived starting up, and the node transitioning a VRRP instance to the MASTER state:

Jul  3 16:29:56 disarm Keepalived: Starting Keepalived v1.1.17 (07/03,2009) Jul  3 16:29:56 disarm Keepalived: Starting VRRP child process, pid=1889 Jul  3 16:29:56 disarm Keepalived_VRRP: Using MII-BMSR NIC polling thread... Jul  3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink reflector Jul  3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink command channel Jul  3 16:29:56 disarm Keepalived_VRRP: Registering gratutious ARP shared channel Jul  3 16:29:56 disarm Keepalived_VRRP: Opening file '/usr/local/etc/keepalived.conf'. Jul  3 16:29:56 disarm Keepalived_VRRP: Configuration is using : 62990 Bytes Jul  3 16:29:57 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Transition to MASTER STATE Jul  3 16:29:58 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Entering MASTER STATE Jul  3 16:29:58 disarm Keepalived_VRRP: Netlink: skipping nl_cmd msg... 

If you are unable to determine the source of a problem with the system logs, you can use tcpdump to display the VRRP advertisements that are sent on the local network. Advertisements are sent to a reserved VRRP multicast address (224.0.0.18), so the following filter can be used to display all VRRP traffic that is visible on the interface passed to the "-i" option:

$ tcpdump -vvv -n -i br0 host 224.0.0.18 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes  10:18:23.621512 IP (tos 0x0, ttl 255, id 102, offset 0, flags [none], proto VRRP (112), length 40) \                 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple,                  intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746"  10:18:25.621977 IP (tos 0x0, ttl 255, id 103, offset 0, flags [none], proto VRRP (112), length 40) \                 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple,                  intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746"                          ......... 

The output contains several pieces of data that be useful for debugging problems:

authtype - the type of authentication in use (authentication configuration directive) vrid - the virtual router id (virtual_router_id configuration directive) prio - the priority of the device (priority configuration directive) intvl - how often to send out advertisements (advert_int configuration directive) auth - the authentication token sent (auth_pass configuration directive) 

Conclusion

---

In this article I described how to set up a host to use the keepalived daemon, and provided a sample configuration file that can be used to failover virtual interfaces between servers. Keepalived has a slew of options not covered here, and I will refer you to the keepalived source code and documentation for additional details

在Keepalived集群中，其實(shí)并沒有嚴(yán)格意義上的主、備節(jié)點(diǎn)，雖然可以在Keepalived配置文件中設(shè)置“state”選項(xiàng)為“MASTER”狀態(tài)，但是這并不意味著此節(jié)點(diǎn)一直就是Master角色。控制節(jié)點(diǎn)角色的是Keepalived配置文件中的“priority”值，但并它并不控制所有節(jié)點(diǎn)的角色，另一個(gè)能改變節(jié)點(diǎn)角色的是在vrrp_script模塊中設(shè)置的“weight”值，這兩個(gè)選項(xiàng)對(duì)應(yīng)的都是一個(gè)整數(shù)值，其中“weight”值可以是個(gè)負(fù)整數(shù)，一個(gè)節(jié)點(diǎn)在集群中的角色就是通過這兩個(gè)值的大小決定的。

在一個(gè)一主多備的Keepalived集群中，“priority”值最大的將成為集群中的Master節(jié)點(diǎn)，而其他都是Backup節(jié)點(diǎn)。在Master節(jié)點(diǎn)發(fā)生故障后，Backup節(jié)點(diǎn)之間將進(jìn)行“民主選舉”，通過對(duì)節(jié)點(diǎn)優(yōu)先級(jí)值“priority”和““weight”的計(jì)算，選出新的Master節(jié)點(diǎn)接管集群服務(wù)。

在vrrp_script模塊中，如果不設(shè)置“weight”選項(xiàng)值，那么集群優(yōu)先級(jí)的選擇將由Keepalived配置文件中的“priority”值決定，而在需要對(duì)集群中優(yōu)先級(jí)進(jìn)行靈活控制時(shí)，可以通過在vrrp_script模塊中設(shè)置“weight”值來實(shí)現(xiàn)。下面列舉一個(gè)實(shí)例來具體說明。

假定有A和B兩節(jié)點(diǎn)組成的Keepalived集群，在A節(jié)點(diǎn)keepalived.conf文件中，設(shè)置“priority”值為100，而在B節(jié)點(diǎn)keepalived.conf文件中，設(shè)置“priority”值為80，并且A、B兩個(gè)節(jié)點(diǎn)都使用了“vrrp_script”模塊來監(jiān)控mysql服務(wù)，同時(shí)都設(shè)置“weight”值為10，那么將會(huì)發(fā)生如下情況。

在兩節(jié)點(diǎn)都啟動(dòng)Keepalived服務(wù)后，正常情況是A節(jié)點(diǎn)將成為集群中的Master節(jié)點(diǎn)，而B自動(dòng)成為Backup節(jié)點(diǎn)，此時(shí)將A節(jié)點(diǎn)的mysql服務(wù)關(guān)閉，通過查看日志發(fā)現(xiàn)，并沒有出現(xiàn)B節(jié)點(diǎn)接管A節(jié)點(diǎn)的日志，B節(jié)點(diǎn)仍然處于Backup狀態(tài)，而A節(jié)點(diǎn)依舊是Master狀態(tài)，在這種情況下整個(gè)HA集群將失去意義。

下面就分析一下產(chǎn)生這種情況的原因，這也就是Keepalived集群中主、備角色選舉策略的問題。下面總結(jié)了在Keepalived中使用vrrp_script模塊時(shí)整個(gè)集群角色的選舉算法，由于“weight”值可以是正數(shù)也可以是負(fù)數(shù)，因此，要分兩種情況進(jìn)行說明。

1. “weight”值為正數(shù)時(shí)

在vrrp_script中指定的腳本如果檢測(cè)成功，那么Master節(jié)點(diǎn)的權(quán)值將是“weight值與”priority“值之和，如果腳本檢測(cè)失敗，那么Master節(jié)點(diǎn)的權(quán)值保持為“priority”值，因此切換策略為：

Master節(jié)點(diǎn)“vrrp_script”腳本檢測(cè)失敗時(shí)，如果Master節(jié)點(diǎn)“priority”值小于Backup節(jié)點(diǎn)“weight值與”priority“值之和，將發(fā)生主、備切換。

Master節(jié)點(diǎn)“vrrp_script”腳本檢測(cè)成功時(shí)，如果Master節(jié)點(diǎn)“weight”值與“priority”值之和大于Backup節(jié)點(diǎn)“weight”值與“priority”值之和，主節(jié)點(diǎn)依然為主節(jié)點(diǎn)，不發(fā)生切換。

2. “weight”值為負(fù)數(shù)時(shí)

在“vrrp_script”中指定的腳本如果檢測(cè)成功，那么Master節(jié)點(diǎn)的權(quán)值仍為“priority”值，當(dāng)腳本檢測(cè)失敗時(shí)，Master節(jié)點(diǎn)的權(quán)值將是“priority“值與“weight”值之差，因此切換策略為：

Master節(jié)點(diǎn)“vrrp_script”腳本檢測(cè)失敗時(shí)，如果Master節(jié)點(diǎn)“priority”值與“weight”值之差小于Backup節(jié)點(diǎn)“priority”值，將發(fā)生主、備切換。

Master節(jié)點(diǎn)“vrrp_script”腳本檢測(cè)成功時(shí)，如果Master節(jié)點(diǎn)“priority”值大于Backup節(jié)點(diǎn)“priority”值時(shí)，主節(jié)點(diǎn)依然為主節(jié)點(diǎn)，不發(fā)生切換。

在熟悉了Keepalived主、備角色的選舉策略后，再來分析一下剛才實(shí)例，由于A、B兩個(gè)節(jié)點(diǎn)設(shè)置的“weight”值都為10，因此符合選舉策略的第一種，在A節(jié)點(diǎn)停止Mysql服務(wù)后，A節(jié)點(diǎn)的腳本檢測(cè)將失敗，此時(shí)A節(jié)點(diǎn)的權(quán)值將保持為A節(jié)點(diǎn)上設(shè)置的“priority”值，即為100，而B節(jié)點(diǎn)的權(quán)值將變?yōu)?#8220;weight”值與“priority”值之和，也就是90（10+80），這樣就出現(xiàn)了A節(jié)點(diǎn)權(quán)值仍然大于B節(jié)點(diǎn)權(quán)值的情況，因此不會(huì)發(fā)生主、備切換。

對(duì)于“weight”值的設(shè)置，有一個(gè)簡(jiǎn)單的標(biāo)準(zhǔn)，即“weight”值的絕對(duì)值要大于Master和Backup節(jié)點(diǎn)“priority”值之差。對(duì)于上面A、B兩個(gè)節(jié)點(diǎn)的例子，只要設(shè)置“weight”值大于20即可保證集群正常運(yùn)行和切換。由此可見，對(duì)于“weight值的設(shè)置，要非常謹(jǐn)慎，如果設(shè)置不好，將導(dǎo)致集群角色選舉失敗，使集群陷于癱瘓狀態(tài)。

如果你在讀這篇文章，說明你跟大多數(shù)開發(fā)者一樣對(duì)GIT感興趣，如果你還沒有機(jī)會(huì)來試一試GIT，我想現(xiàn)在你就要了解它了。

GIT不僅僅是個(gè)版本控制系統(tǒng)，它也是個(gè)內(nèi)容管理系統(tǒng)(CMS),工作管理系統(tǒng)等。如果你是一個(gè)具有使用SVN背景的人，你需要做一定的思想轉(zhuǎn)換，來適應(yīng)GIT提供的一些概念和特征。所以，這篇文章的主要目的就是通過介紹GIT能做什么、它和SVN在深層次上究竟有什么不同來幫助你認(rèn)識(shí)它。

那好，這就開始吧…

1.GIT是分布式的，SVN不是：

這是GIT和其它非分布式的版本控制系統(tǒng)，例如SVN，CVS等，最核心的區(qū)別。如果你能理解這個(gè)概念，那么你就已經(jīng)上手一半了。需要做一點(diǎn)聲明，GIT并不是目前第一個(gè)或唯一的分布式版本控制系統(tǒng)。還有一些系統(tǒng)，例如Bitkeeper, Mercurial等，也是運(yùn)行在分布式模式上的。但GIT在這方面做的更好，而且有更多強(qiáng)大的功能特征。

GIT跟SVN一樣有自己的集中式版本庫(kù)或服務(wù)器。但，GIT更傾向于被使用于分布式模式，也就是每個(gè)開發(fā)人員從中心版本庫(kù)/服務(wù)器上chect out代碼后會(huì)在自己的機(jī)器上克隆一個(gè)自己的版本庫(kù)。可以這樣說，如果你被困在一個(gè)不能連接網(wǎng)絡(luò)的地方時(shí)，就像在飛機(jī)上，地下室，電梯里等，你仍然能夠提 交文件，查看歷史版本記錄，創(chuàng)建項(xiàng)目分支，等。對(duì)一些人來說，這好像沒多大用處，但當(dāng)你突然遇到?jīng)]有網(wǎng)絡(luò)的環(huán)境時(shí)，這個(gè)將解決你的大麻煩。

同樣，這種分布式的操作模式對(duì)于開源軟件社區(qū)的開發(fā)來說也是個(gè)巨大的恩賜，你不必再像以前那樣做出補(bǔ)丁包，通過email方式發(fā)送出去，你只需要?jiǎng)?chuàng)建一個(gè)分支，向項(xiàng)目團(tuán)隊(duì)發(fā)送一個(gè)推請(qǐng)求。這能讓你的代碼保持最新，而且不會(huì)在傳輸過程中丟失。GitHub.com就是一個(gè)這樣的優(yōu)秀案例。

有些謠言傳出來說subversion將來的版本也會(huì)基于分布式模式。但至少目前還看不出來。

2.GIT把內(nèi)容按元數(shù)據(jù)方式存儲(chǔ)，而SVN是按文件：

所有的資源控制系統(tǒng)都是把文件的元信息隱藏在一個(gè)類似.svn,.cvs等的文件夾里。如果你把.git目錄的 體積大小跟.svn比較，你會(huì)發(fā)現(xiàn)它們差距很大。因?yàn)?.git目錄是處于你的機(jī)器上的一個(gè)克隆版的版本庫(kù)，它擁有中心版本庫(kù)上所有的東西，例如標(biāo)簽，分 支，版本記錄等。

3.GIT分支和SVN的分支不同：

分支在SVN中一點(diǎn)不特別，就是版本庫(kù)中的另外的一個(gè)目錄。如果你想知道是否合并了一個(gè)分支，你需要手工運(yùn)行像這樣的命令svn propget svn:mergeinfo，來確認(rèn)代碼是否被合并。感謝Ben同學(xué)指出這個(gè)特征。所以，經(jīng)常會(huì)發(fā)生有些分支被遺漏的情況。

然而，處理GIT的分支卻是相當(dāng)?shù)暮?jiǎn)單和有趣。你可以從同一個(gè)工作目錄下快速的在幾個(gè)分支間切換。你很容易發(fā)現(xiàn)未被合并的分支，你能簡(jiǎn)單而快捷的合并這些文件。

4.GIT沒有一個(gè)全局的版本號(hào)，而SVN有：

目前為止這是跟SVN相比GIT缺少的最大的一個(gè)特征。你也知道，SVN的版本號(hào)實(shí)際是任何一個(gè)相應(yīng)時(shí)間的源代 碼快照。我認(rèn)為它是從CVS進(jìn)化到SVN的最大的一個(gè)突破。因?yàn)镚IT和SVN從概念上就不同，我不知道GIT里是什么特征與之對(duì)應(yīng)。如果你有任何的線 索，請(qǐng)?jiān)谠u(píng)論里奉獻(xiàn)出來與大家共享。

更新：有些讀者指出，我們可以使用GIT的SHA-1來唯一的標(biāo)識(shí)一個(gè)代碼快照。這個(gè)并不能完全的代替SVN里容易閱讀的數(shù)字版本號(hào)。但，用途應(yīng)該是相同的。

5.GIT的內(nèi)容完整性要優(yōu)于SVN：

GIT的內(nèi)容存儲(chǔ)使用的是SHA-1哈希算法。這能確保代碼內(nèi)容的完整性，確保在遇到磁盤故障和網(wǎng)絡(luò)問題時(shí)降低對(duì)版本庫(kù)的破壞。這里有一個(gè)很好的關(guān)于GIT內(nèi)容完整性的討論 –http://stackoverflow.com/questions/964331/git-file-integrity

GIT和SVN之間只有這五處不同嗎？當(dāng)然不是。我想這5個(gè)只是“最基本的”和“最吸引人”的，我只想到這5點(diǎn)。如果你發(fā)現(xiàn)有比這5點(diǎn)更有趣的，請(qǐng)共享出來，歡迎。

mysql中 myisam 引擎不支持事務(wù)的概念，多用于數(shù)據(jù)倉(cāng)庫(kù)這樣查詢多而事務(wù)少的情況，速度較快。
mysql中 innoDB 引擎支持事務(wù)的概念，多用于web網(wǎng)站后臺(tái)等實(shí)時(shí)的中小型事務(wù)處理后臺(tái)。

而oracle沒有引擎的概念，oracle有OLTP和OLAP模式的區(qū)分，兩者的差別不大，只有參數(shù)設(shè)置上的不同。
oracle無(wú)論哪種模式都是支持事務(wù)概念的，oracle是一個(gè)不允許讀臟的數(shù)據(jù)庫(kù)系統(tǒng)。



當(dāng)今的數(shù)據(jù)處理大致可以分成兩大類：聯(lián)機(jī)事務(wù)處理OLTP（on-line transaction processing）、聯(lián)機(jī)分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。OLAP是數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果.
OLTP:
也稱為面向交易的處理系統(tǒng)，其基本特征是顧客的原始數(shù)據(jù)可以立即傳送到計(jì)算中心進(jìn)行處理，并在很短的時(shí)間內(nèi)給出處理結(jié)果。
這樣做的最大優(yōu)點(diǎn)是可以即時(shí)地處理輸入的數(shù)據(jù)，及時(shí)地回答。也稱為實(shí)時(shí)系統(tǒng)(Real time System)。衡量聯(lián)機(jī)事務(wù)處理系統(tǒng)的一個(gè)重要性能指標(biāo)是系統(tǒng)性能，具體體現(xiàn)為實(shí)時(shí)響應(yīng)時(shí)間(Response Time)，即用戶在終端上送入數(shù)據(jù)之后，到計(jì)算機(jī)對(duì)這個(gè)請(qǐng)求給出答復(fù)所需要的時(shí)間。OLTP是由數(shù)據(jù)庫(kù)引擎負(fù)責(zé)完成的。
OLTP 數(shù)據(jù)庫(kù)旨在使事務(wù)應(yīng)用程序僅寫入所需的數(shù)據(jù)，以便盡快處理單個(gè)事務(wù)。
OLAP:
簡(jiǎn)寫為OLAP,隨著數(shù)據(jù)庫(kù)技術(shù)的發(fā)展和應(yīng)用，數(shù)據(jù)庫(kù)存儲(chǔ)的數(shù)據(jù)量從20世紀(jì)80年代的兆（M）字節(jié)及千兆（G）字節(jié)過渡到現(xiàn)在的兆兆（T）字節(jié)和千兆兆（P）字節(jié)，同時(shí)，用戶的查詢需求也越來越復(fù)雜，涉及的已不僅是查詢或操縱一張關(guān)系表中的一條或幾條記錄，而且要對(duì)多張表中千萬(wàn)條記錄的數(shù)據(jù)進(jìn)行數(shù)據(jù)分析和信息綜合，關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)已不能全部滿足這一要求。在國(guó)外，不少軟件廠商采取了發(fā)展其前端產(chǎn)品來彌補(bǔ)關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)支持的不足，力圖統(tǒng)一分散的公共應(yīng)用邏輯，在短時(shí)間內(nèi)響應(yīng)非數(shù)據(jù)處理專業(yè)人員的復(fù)雜查詢要求。
聯(lián)機(jī)分析處理（OLAP）系統(tǒng)是數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)最主要的應(yīng)用，專門設(shè)計(jì)用于支持復(fù)雜的分析操作，側(cè)重對(duì)決策人員和高層管理人員的決策支持，可以根據(jù)分析人員的要求快速、靈活地進(jìn)行大數(shù)據(jù)量的復(fù)雜查詢處理，并且以一種直觀而易懂的形式將查詢結(jié)果提供給決策人員，以便他們準(zhǔn)確掌握企業(yè)（公司）的經(jīng)營(yíng)狀況，了解對(duì)象的需求，制定正確的方案。

第一種：直接啟動(dòng)
安裝：
啟動(dòng)：
檢測(cè)：

停止：


第二種：通過指定配置文件啟動(dòng)




第三種：

mysql mysqldump 只導(dǎo)出表結(jié)構(gòu) 不導(dǎo)出數(shù)據(jù)

備份數(shù)據(jù)庫(kù)

#mysqldump　數(shù)據(jù)庫(kù)名　>數(shù)據(jù)庫(kù)備份名
#mysqldump　-A　-u用戶名　-p密碼　數(shù)據(jù)庫(kù)名>數(shù)據(jù)庫(kù)備份名
#mysqldump　-d　-A　--add-drop-table　-uroot　-p　>xxx.sql
1.導(dǎo)出結(jié)構(gòu)不導(dǎo)出數(shù)據(jù)
mysqldump　--opt　-d　數(shù)據(jù)庫(kù)名　-u　root　-p　>　xxx.sql　　
2.導(dǎo)出數(shù)據(jù)不導(dǎo)出結(jié)構(gòu)
mysqldump　-t　數(shù)據(jù)庫(kù)名　-uroot　-p　>　xxx.sql　
3.導(dǎo)出數(shù)據(jù)和表結(jié)構(gòu)
4.導(dǎo)出特定表的結(jié)構(gòu)
mysqldump　-uroot　-p　-B　數(shù)據(jù)庫(kù)名　--table　表名　>　xxx.sql　　
導(dǎo)入數(shù)據(jù)：
　　由于mysqldump導(dǎo)出的是完整的SQL語(yǔ)句，所以用mysql客戶程序很容易就能把數(shù)據(jù)導(dǎo)入了：
#mysql　數(shù)據(jù)庫(kù)名　<　文件名
#source　/tmp/xxx.sql　　 

Haproxy根目錄：F:\SysWork\openSource\haproxy\haproxy1.5.12

配置文件haproxy.cfg如下：

nginx的根目錄是：D:\Sys\server\nginx\nginx-1.9.4\

nginx配置文件目錄：D:\Sys\server\nginx\nginx-1.9.4\conf
nginx.conf 配置文件如下：


在該目錄下面創(chuàng)建vhosts目錄：
虛擬主機(jī)(實(shí)際里面就是配置upstream和server，然后server里面配置監(jiān)聽端口和serverName，還有l(wèi)ocation)目錄里面的配置文件分別為：
www.abin.com.conf
www.lee.com.conf

www.abin.com.conf的配置為：



測(cè)試：
http://www.lee.com:8000/

那么上面的第二個(gè)地址打印hello，abin
那么上面的第四個(gè)地址打印hello，lee


本地hosts文件配置為：

環(huán)境

配置Mysql的MasterSlave至少需要兩臺(tái)機(jī)器。我這里使用三臺(tái)虛擬機(jī)進(jìn)行測(cè)試。三臺(tái)機(jī)器配置完全一樣，MySQL安裝的路徑也是一樣：

第一臺(tái)：10.1.5.181； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1

第二臺(tái)：10.1.5.182； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1

第三臺(tái)：10.1.5.183； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1

 

第一臺(tái)10.1.5.181用作master，其他兩臺(tái)用做slave。

配置Master

在10.1.5.181這臺(tái)服務(wù)器上找到MySQL的配置文件my.ini。我的具體路徑是在C:\ProgramData\MySQL\MySQL Server 5.6下。

打開配置文件，在最下面添加如下配置：

************************************************************************************

#Master start
#日志輸出地址 主要同步使用
log-bin=master-bin.log
#同步數(shù)據(jù)庫(kù)
binlog-do-db=test
#主機(jī)id 不能和從機(jī)id重復(fù)
server-id=1
#Master end

************************************************************************************

master的配置比較少，server-id是為這一組master/slave服務(wù)器定的唯一id，master/slave服務(wù)器中不能重復(fù)。在binlog-do-db中填寫對(duì)象要同步的數(shù)據(jù)庫(kù)，如果有多個(gè)，用逗號(hào)分隔，或再寫一行如binlog-do-db=test2。

 

配置Slave

同樣在第二臺(tái)機(jī)器上10.1.5.181找到配置文件my.ini。打開配置文件，在最下面添加如下配置：

*****************************************************************************

report-host = 10.1.5.181
report-user = root
report-password = root123
log-bin = slave-bin.log
replicate-do-db = test

server-id = 2

*****************************************************************************

這里需要添加master的IP，連接master的用戶名和密碼，生產(chǎn)環(huán)境中需要新建一個(gè)用戶專門來處理replication，這里沒有新建用戶，用root做測(cè)試。端口沒有配置，就是使用默認(rèn)的3306，如果端口有變化，則通過report-port=？來配置。log-bin是記錄日志的位置。

然后通過命令start slave來啟動(dòng)mysql的復(fù)制功能。如果在start slave過程中出現(xiàn)異常：

The server is not configured as slave; fix in config file or with CHANGE MASTER TO

可以通過下面語(yǔ)句解決：

change master to master_host='10.1.5.181',master_user='root',master_password='root123',master_log_file='master-bin.000001' ,master_log_pos=120;

使用show slave status 命令來查來看運(yùn)行狀態(tài)。特別關(guān)注兩個(gè)屬性，是否為“Yes”，如果都為“Yes”，則說明運(yùn)行正常。

Slave_IO_Running：連接到主庫(kù)，并讀取主庫(kù)的日志到本地，生成本地日志文件

Slave_SQL_Running:讀取本地日志文件，并執(zhí)行日志里的SQL命令。

 

同樣的配置再在第三臺(tái)機(jī)器上配置一下，server-id修改成3。重啟slave和master的mysqld服務(wù)。然后測(cè)試，在三臺(tái)服務(wù)器上都確保有數(shù)據(jù)庫(kù)test，然后在master服務(wù)器的test數(shù)據(jù)庫(kù)上建表和數(shù)據(jù)，之后再兩臺(tái)slave上面都會(huì)看見數(shù)據(jù)的同步。

 

Mysql的MasterSlave同步時(shí)通過二進(jìn)制文件進(jìn)行同步的。在Master端，你可以在C:\ProgramData\MySQL\MySQL Server 5.6\data的master-bin.log日志文件里看見所有同步的sql腳本，master-bin.log是配置master時(shí)候輸入的。在slave端，你可以在MySQL02-relay-bin類似的文件中找到日志。