启动resin时，报出javax.naming.NameNotFoundException: java:comp/env//jms/FailoverConnectionFactory？

顾名思义，oracle的failover是指在oracle集群汇总，客户端当前连接的实例发生故障时，oracle会自动将连接切换到另外一个实例上的情况。或者说，当用户连接到RAC环境时，用户实际是连接到RAC中的一个实例，用户的查询等操作也是由该实例完成的，如果该实例down掉了，那么用户连接会被转移到其他健康实例，而这种转换对于用户是透明的，用户的select语句仍然继续返回结果集，感觉不到异常。可以尝试通过下面实例来体现以下：1，连接到rac$sqlplususer/password@instance1;2,确认用户当前连接的实例SQL>slectinstance_namefromv$instance;instance1;3,关闭instance1SQL>shutdownabort;4,等待几秒后，在第一次连接的session中继续执行查询；SQL>slectinstance_namefromv$instance;instance2;

服务的可用性不仅仅是指服务健康运行的时间，还包括出现故障以后的恢复速度。保证一个服务的高可用，基本可以从 软件质量 故障预防 故障恢复三方面着手。对于redis，软件的质量本身有很大的保障，因此对于线上大规模的redis集群运维管理，基本上可以从故障预防和故障恢复两方面着。虽然redis cluster本身具有自动主从容灾的高可用能力，但是某些场景cluster依然无法很好地处理。本文将结合CLUSTER FAILOVER 集群管理命令详细介绍如何进一步提升redis集群的可用性。 首先对CLUSTER FAILOVER命令做个介绍: CLUSTER FAILOVER处理流程 该操作用于正常的主从切换，但是如果master节点宕机了无法响应failover请求，那么failover将会失败，为了处理master宕机的情况，可以添加FORCE 选项。 CLUSTER FAILOVER FORCE: 添加FORCE选项时，failover流程直接从上述的第4步开始，也即跳过了和旧master通信协商复制数据的过程，当master宕机时，force选项可以快速进行人工主从切换。但是该过程仍然需要获得半数master的统=同意才能当选为新主。当出现半数master节点异常时，该流程无法进行主从切换。 CLUSTER FAILOVER TAKEOVER: 为了处理半数master节点异常的场景，可以添加****TAKEOVER 选项。通过TAKEOVER 选项，可以无需获得半数master的认同，而是直接更新状态为master并向所有可达的节点发送最新配置epoch。**** 接下来将结合场景介绍如何通过FAILOVER 提升集群可用性 防患以未然，当机器负载过高或者出现异常故障时，需要将部署在该机器的redis实例迁移出,迁移流程包含: 如果旧机器有实例处于master，则需要先将role改外slave，然后在进行迁移，此时可以通过对slave节点发送cluster failover，将节点改为slave以后在进行删除。 最理想的情况是出现故障之前提前解决处理，但是这毕竟只是理想。当节点宕机或者负载过高导致无法响应时，可能出现FAILOVER失败的情况，此时则可以通过添加FORCE选项进行强制主从切换，将健康的slave节点提升为master从而快速恢复服务。 虽然在线上环境的部署上，redis的master节点会做到尽可能分散，但是在某些场景写，还是可能出现半数master节点故障的情况: 虽然redis cluster本身提供了高可用的能力，但是在某些场景下依然需要人为介入进行处理，本文介绍了FAILOVER的几种应用实践场景，通过将该操作和option集成到自动运维平台，进一步提升了redis的可用性。

在Dubbo中使用Hystrix后，failover依然会起作用。Hystrix是一种熔断器模式的实现，用于处理分布式系统中的故障和延迟。当使用Hystrix时，Dubbo会将Hystrix作为服务调用的容错策略之一。failover是Dubbo中的一种容错策略，用于在远程调用失败时进行重试。它通过设置retries参数来确定重试的次数。当使用Hystrix时，Dubbo会首先尝试通过Hystrix进行服务调用，如果Hystrix触发熔断或发生错误，Dubbo会根据failover策略进行重试。也就是说，如果使用Hystrix后出现远程调用失败，Dubbo仍然会触发failover机制进行重试。需要注意的是，Hystrix和failover是可以同时使用的，但它们是两种不同的容错策略。Hystrix主要用于处理服务内部的故障和延迟，而failover主要用于处理远程服务调用失败。在使用Hystrix时，可以根据具体的业务需求来选择是否需要同时使用failover策略。

故障倒换的意思，两台防火墙通过心跳线级联，一台作为另外一台的热备。

Windows 故障转移群集系列文档最后一部分，本文将在 Part 1 和 Part2 的基础之上部署高可用的文件服务器和基于CSV的高可用Hyper-V集群 在上两篇文章中，我们已经创建好了群集 ClusterA ,两个节点分别是ServerA1和SevrerA2。 在为集群ClusterA配置文件服务之前，每个节点上面都需预先安装文件服务，如下： Windows故障转移（ Failover ）在发生如下几种情况时， Failover 将会把运行于群集活动节点上面的资源转移到另一个节点 故障转移过程中，将根据依赖级别，依次将资源离线，它总是先离线依赖资源，后离线被依赖的资源。例如，如果当前群集运行的服务依赖于群集磁盘，那么集群服务会首先被离线，以便将离线产生的更改写入到磁盘。所有资源离线之后，集群服务将根据集群中角色有所有者偏好设置的顺序在选中的下一个节点上将该实例重新安置。 所有资源离线后，群集服务将尝试将群集角色根据角色所有者偏好顺序设置转移到下一个节点，一旦角色被转移到另一个节点，群集服务将尝试以在所有资源脱机相反的顺序使资源上线。在我们上述群磁盘和服务的实列中，磁盘先上线，然后服务再上线，以保证服务不会尝试向未上线的磁盘写入数据。 传统的windows故障转移集群部署中，多个节点不能同时访问同一个LUN或一个在共享存储上的卷。 CSV 能够实现在同一时间共享同一个LUN。每个节点获得对单个文件的独占访问权而不是对整个LUN的。 CSVs 作为一种分布式文件访问的解决方案允许集群中的多个阶段同时访问被格式化成NTFS和（ Resilient File System 弹性文件系统,从Windows Server 2012 R2开始引入 )ReFS。 CSVs 仅能在集群中创建 Hyper-V 集群仅能被配置在物理机上（ Host Clustering )，而不能被配置在虚拟机上( Guest Clustering ) 部署Hyper-V的host clustering集群允许将虚拟机作为故障转移保护的资源，运行在guest虚拟机之上的应用和操作系统是没有集群感知的，但是虚拟机仍然可以实现高可用性。 配置虚拟机高可用集群前，所有节点事先需要安装Hyper-V角色

证书出问题了，建议直接从装软件，这样最简单，不然找问题更加麻烦

Linux网卡bonding随着科学技术的日益革新，数据的安全性已经逐渐体现出了它的重要意义。可以设想，当一个人所有的个人资料都不负存在，那是多么可怕的事情。网络技术的深入使用，数据的网络化传输已经成为了重要，甚至主要的传输方式。所以数据服务器能够正常提供网络服务是所有供应商都需要考虑的问题。在这个背景下，单网卡的应用已经捉襟见肘，设备冗余技术的普及已是枝繁叶茂。本文之后就引用Linux操作系统下的多网卡bonding技术来阐述这一容错概念。负载均衡功能也是网卡bonding的另一个功能，它可以实现多网卡同时工作，提高系统网络处理的吞吐能力。一、网卡的负载均衡模式（mode = BOND_MODE_ROUNDROBIN）1）建立bond虚设备建立一个ifcfg-bond0的设备，然后配置如下信息即可。DEVICE=bond0BOOTPROTO=staticIPADDR=172.16.64.208NETMASK=255.255.224.0ONBOOT=yesTYPE=Ethernet2）配置接口文件由于使用一个虚拟的ip地址，所以，其他接口设备都不配置ip信息。3）配置bonding工作方式打开/etc/modprobe.conf文件，将bonding的工作模式配置为如下模式。alias bond0 bondingoptions bond0 mode=0 arp_interval=500 arp_ip_target=172.16.64.864）启动bonding需要添加路由来制定发送规则，这个可以自定义添加。配置完后重启设备即可。ifenslave bond0 eth0 eth1route add -net 0/0 gw 172.16.64.254bond0 Link encap:Ethernet HWaddr 00:14:10:70:00:25 inet addr:172.16.64.208 Bcast:172.16.95.255 Mask:255.255.224.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:39335 errors:0 dropped:0 overruns:0 frame:0 TX packets:3178 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3020656 (2.8 MiB) TX bytes:269722 (263.4 KiB)eth0 Link encap:Ethernet HWaddr 00:14:10:70:00:25 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:18208 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1371589 (1.3 MiB) TX bytes:378 (378.0 b)eth1 Link encap:Ethernet HWaddr 00:14:10:70:00:25 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:21128 errors:0 dropped:0 overruns:0 frame:0 TX packets:3174 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1649127 (1.5 MiB) TX bytes:269498 (263.1 KiB)如上图所示，这种模式下bonding模块会将虚接口和所有的slave接口的MAC地址设置为一致。通过定时器，每个slave接口不断发送ARP包来不断更换交换机端口与MAC的对应关系。这样使得每个网卡都在进行工作。这个ARP的发送规则是：每arp_interval（MS）间隔向arp_ip_target发送arp请求。也可以向多个arp_ip_target发送arp请求。观察交换机端口上所学习到的MAC地址，发现MAC会在两个端口上反复切换。在BOND_MODE_ROUNDROBIN模式下，bonding对于发送和接收数据的处理逻辑是不一致的，对于数据的接收，bonding基本不做任何处理，纯粹依靠交换机端口与MAC的变化来实现交替接收数据。发送的话，交换机会根据数据的源MAC来学习端口和MAC之间的关系，所以bonding做到的就是选择不一样的网卡发送。对于数据的发送，static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode){ switch (mode) { case BOND_MODE_ROUNDROBIN: bond_dev->hard_start_xmit = bond_xmit_roundrobin; break; ... bond的发送函数被注册为bond_xmit_roundrobin。通过bond_xmit_roundrobin的实现可以发现static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev){ read_lock(&bond->curr_slave_lock); slave = start_at = bond->curr_active_slave; read_unlock(&bond->curr_slave_lock); bond_for_each_slave_from(bond, slave, i, start_at) { if (IS_UP(slave->dev) && (slave->link == BOND_LINK_UP) &&(slave->state == BOND_STATE_ACTIVE)) {res = bond_dev_queue_xmit(bond, skb, slave->dev);write_lock(&bond->curr_slave_lock);bond->curr_active_slave = slave->next;write_unlock(&bond->curr_slave_lock);break;}bond_xmit_roundrobin会通过curr_active_slave指针所指向的设备来进行发送，当然curr_active_slave会在调用bond_dev_queue_xmit完成实际的发送之后指向下一个slave设备。bond_dev_queue_xmit实际是调用通用的发送函数dev_queue_xmit来进行的，它传递给dev_queue_xmit的是一个skb，在传递之前skb->dev就被指定为了当前的slave设备，这样内核就会找到对应的真实网卡设备来进行发送，最后curr_active_slave指针的轮询切换，实现了bonding的负载均衡工作模式。从这种模式可以看到，bonding实现了一个类似网卡驱动的模块，对应的bond0设备是一个纯粹的虚设备，数据发送虽然说经过了它，但通过一系列调用，转了一圈之后才回到真正的网卡设备那里进行发送，无疑会消耗一定的系统性能。简单用100Mbps速率的UDP数据包测试了一下BOND_MODE_ROUNDROBIN模式。测试过程中发现接收端会有较多的乱序包，观察交换机端口情况，端口之间的切换频率不规则，这个和交换机的配置或者性能应该有很大联系，有必要的话需要进一步研究。数据的正确性和时序性能否保证需要进一步仔细测试。2、网卡的容错模式（mode = BOND_MODE_ACTIVEBACKUP）容错模式的配置方法和负载均衡模式基本差不多，只不过修改一下/etc/modprobe.conf即可。alias bond0 bondingoptions bond0 mode=1 miimon=100这里使用的是mii链路检测方式，与之前arp检测方式不同。当然这两种链路检测方式在各种mode下都是可以使用的，但要注意不能同时使用。介绍一下bonding的mii检测实现。首先和arp-monitor一样，mii也是定时器触发 if (bond->params.miimon) { /* link check interval, in milliseconds. */ init_timer(mii_timer); mii_timer->expires = jiffies + 1; mii_timer->data = (unsigned long)bond_dev; mii_timer->function = (void *)&bond_mii_monitor; add_timer(mii_timer); }bond_mii_monitor函数其本质的原理就是检测网卡的链路状态，bonding定义网卡有4个链路状态：BOND_LINK_UP： 正常状态（处于该状态的网卡是是潜在的发送数据包的候选者）BOND_LINK_FAIL： 网卡出现故障，向状态BOND_LINK_DOWN 切换中BOND_LINK_DOWN： 失效状态BOND_LINK_BACK： 网卡恢复，向状态BOND_LINK_UP切换中从上到下，表示了网卡链路从正常到失效再到恢复状态。bond_mii_monitor函数就是依次检查网卡的链路状态是否处于这些状态，然后通过标记do_failover变量来说明当前是否需要切换slave网卡。代码篇幅较大，但逻辑还是很清晰的，故此处不罗列了。在BOND_MODE_ACTIVEBACKUP模式下，两块网卡其实有一块是不工作的，被设置为IFF_NOARP的状态。同时，bond虚设备，还有slave设备的MAC地址均一致，所以这张网卡不会被外界察觉存在。交换机也不存在想该端口发包的情况。当bond的mii检测发现当前的active设备失效了之后，会切换到这个备份设备上。在bond_change_active_slave函数中if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {if (old_active) {bond_set_slave_inactive_flags(old_active);}if (new_active) {bond_set_slave_active_flags(new_active);}}这个就是在BOND_MODE_ACTIVEBACKUP模式下的切换逻辑，很简单，需要注意的是，在bond_set_slave_inactive_flags(old_active)中，需要将接口的状态设置为IFF_NOARP，不然交换机就可能会把数据包发送到一个错误的端口上。BOND_MODE_ACTIVEBACKUP模式下的数据发送非常简单，可想而知curr_active_slave指针始终都指向当前可用的设备，所以直接发送就可以，没有之前BOND_MODE_ROUNDROBIN模式下slave设备切换的过程。3、网卡虚拟化方式（mode = BOND_MODE_ALB）经过考察，许多磁盘阵列设备采用了网卡虚拟化方式进行多网卡应用。实际就是Linux的bonding技术。它采用了mode = BOND_MODE_ALB的方式。BOND_MODE_ALB的实现方式比较复杂，还有一些不理解的地方，就不做深入分析了。其核心思想可以用下图解释：从这个图中可以看到，客户端A与服务器的传输使用的是MAC A；而客户端B与服务器传输使用的是MAC B，但对于IP层来说，客户端A与B都与服务器X.X.X.X 的IP地址进行通讯，并不感知底层传输接口的变化。这样，服务器对于客户端整体上的工作模式就处于负载均衡的状态。当然，这个过程的控制就是bonding模块所完成的。通过测试发现两台客户端展现的arp表是一致的，如下（服务器端地址为172.16.64.208，服务器端首选接口的MAC为00-14-10-70-00-25）CLIENT A172.16.64.208 00-14-10-70-00-25 dynamicCLIENT B172.16.64.208 00-14-10-70-00-25 dynamic通过抓包可以看到，两次回复的ARP应答的源MAC地址是不一样的，分别为00-14-10-70-00-25和00-14-10-70-00-26。所以说，能够实现这种处理方法的原因就是bonding修改了ARP应答的源地址导致，使得外界并不感知服务器存在多网卡的状态，在网络上确定了IP和MAC的唯一对应关系，保证了上层业务传输的逻辑一致性。同时内部的处理又交给不同的网卡，实现了负载均衡。另外，也给了我们一定的容错性，当一个接口失效后，bonding会迅速将另外一块网卡设置为首选slave设备，并修改其MAC地址。由于外界学习到的服务器MAC地址始终是不变的，所以链路的状态不会受很大影响。Bonding的模式一共有7种：#define BOND_MODE_ROUNDROBIN 0#define BOND_MODE_ACTIVEBACKUP 1#define BOND_MODE_XOR 2#define BOND_MODE_BROADCAST 3#define BOND_MODE_8023AD 4#define BOND_MODE_TLB 5#define BOND_MODE_ALB 6每种方式都有它的特点，有些需要交换机支持，比如 BOND_MODE_8023AD和BOND_MODE_XOR。本文就介绍了3种方式，可以在无需交换机支持或者简单配置交换机的情况下运行。

linux下的dhcp服务配置linux下的dhcp服务配置,linux下dhcp服务配置教程花城旧梦转载关注0点赞·1359人阅读linux下dhcp服务配置教程发布于 2017-09-05 12:06:09 | 109 次阅读 | 评论: 0 | 来源: 网友投递LinuxLinux是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。这篇文章主要为大家详细介绍了linux下dhcp服务的配置教程，具有一定的参考价值，感兴趣的小伙伴们可以参考一下1、DHCP简介(1)DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)是一个简化主机IP地址分配管理的TCP/IP标准协议，用户可以利用DHCP服务器管理动态的IP地址分配及其他相关的环境配置工作，如：DNS服务器、WINS服务器、Gateway(网关)的设置。(2)DHCP基于客户/服务器模式。当DHCP客户端启动时，它会自动与DHCP服务器通信，由DHCP服务器为DHCP客户端提供自动分配IP地址的服务。(3)安装了DHCP服务软件的服务器称为DHCP服务器，启用了DHCP功能的客户机称为DHCP客户端。2、实验要求架设一台DHCP服务器，并按照下面的要求进行配置：(1)为子网192.168.0.0/24建立一个IP作用域，并将在192.168.0.100~192.168.0.149范围之内的IP地址动态分配给客户机。(2)假设子网中的DNS服务器地址为192.168.0.253，域名为alice.com，将这些参数指定给客户机使用。(3)为某台主机保留192.168.0.120这个IP地址。配置2台DHCP客户机，试测试DHCP服务器的功能。根据要求完成上述DHCP实验，要求撰写完整实验教程(实验拓扑图、图文并茂的实验步骤 )3、实验拓扑4、实验步骤(1)先挂载镜像，配置本地yum源(2)解决网卡不一致问题，配置各主机IP地址(3)将3台主机加入NAT网络，同时将NAT模式的DHCP功能关闭(4)在dhcp-s上安装dhcp服务器(默认未安装)[r

前面有几篇文章介绍了Windows Failver Cluster集群的相关知识和实际案例，请参考如下： 接下来，我们将尝试如何通过Powershell来更高效的部署和管理Windows故障转移群集。实验环境所用的系统版本为Windows Server 2012，但应适用于更高版本。 本文实验环境为两台Windows Server 2012 R2 如上图，出现报错，这是因为我们的每个节点有两块网卡，分别连接不同的网络（192.168.100.0/24 和192.168.199.0/24），如果集群需要向两个网段同时提供服务或者两个节点来自不同的网段，则可以提供多个虚拟IP如下例；如不需要则可以添加-ignorenetwork参数忽略掉 New-Cluster -Name TestClusterA -Node node1,node2 -StaticAddress 192.168.100.220,192.168.199.220 如果我们集群的地址涉及地址都开启DHCP自动获取IP，我们也可以用下面命令创建 New-Cluster -Name TestClusterA -Node node1,node2 创建集群时，我们还可以指定它创建后所在的AD的OU，比如下面的命令 New-Cluster -Name "CN=TestClusterA,OU=Cluster,DC=buffallos,DC=com" -Node node1,node2 -StaticAddress 192.168.100.220 本例将使用比较常用的方式，只指定静态地址和（192.168.100.0/24）的虚拟IP 集群创建成功 对应的计算机和DNS记录已经创建. 小知识 ： 6.将创建好的iSCSI磁盘添加进群集 TestClusterA 2.将创建好的iSCSI磁盘添加进群集 TestClusterA 如果像设置为节点共享文件夹多数仲裁，可以使用如下命令 PS C:> Set-ClusterQuorum -NodeAndFileShareMajority \DCClusterFSW 4.为了方便日后运维，资源可以更改名字，下面我们将加"群集磁盘1"更改为 Witness 用户被分配管理权限后，可以在用户所用的计算机上安装RSAT进行远程管理群集，但是为了安全，不建议将此用户添加到Domain Admins组。 移除某个用户的群集管理权限可以使用 Remove-ClusterAccess PS C:> Remove-ClusterAccess -Cluster TestClusterA BuffallosClusterAdmin 但是这种方式移除用户后，并不能保证该用户已经没有群集权限，因为有可能该用户所隶属的组可能有管理权限，因此如果想明确某个用户不能拥有群集权限可以使用 Block-ClusterAccess ，如下，明确 ClusterAdmin 不能有集群权限 Block-ClusterAccess -Cluster TestClusterA -user buffallosClusterAdmin 7.下面我们将使用powershell快速创建一个群集文件服务角色（ Windows 故障转移群集 Part 3 中详述了图形化创建过程），然后再了解下群集组。 执行上面的函数后，结果如下，我们可以看到， 群集磁盘 3 容量最大，我们将它作为文件服务器存储 我们把磁盘3名称改为F_Disk，方便区分 创建文件服务器FileA并创建共享文件夹E:Data 默认情况下，群集组类型只有群集组和可用存储组，但是在我们创建了文件服务器后，与文件服务器相关的资源都被放在了FileA这个群集组中，如下 我们定义集群组，其目的就是为了方便管理，一般会把所提供服务或应用所用到的资源归为一组，每当需要管理其相关资源时，可以通过组方式筛选 依赖关系还可以添加，下面我们将FileA组中的闲置磁盘添加文件服务器FileA依存关系，使其被后者依赖 注意：添加的依赖逻辑操作符均为逻辑与（AND)，即所有被依赖的资源上线后，依赖者才能上线，下线顺序相反

以管理员身份运行ANSYS,Inc.LicenseManager中的serveranslic_adminutility,选择starttheANSYS,Inc.LicenseManager

有不支持failover的license

我用packet 测试了一下，仅供参考 当我把其中的主用设备down掉后，8秒后备用设备变为active。 我show stanby 发现 HSRP的hello时间间隔为3s hold time 时间为10 s 所以切换的是时间最长为10s 最短为7s，具体设备通过show stanby 查看hsrp 的具体参数即可 主用切换到备用的时候会造成短时间的通讯中断，中断时间即为切换时间，但当主用恢复后，切换回主用时不会造成通讯中断，（前提是配置一个合适的抢占延时 ，或者手动切换。） 后期我用gns再测试一下，有新结果再发给你。

在开启了 Kerberos 验证的集群中，启用了 HA 模式的 HDFS 报错未正常运行，且 Failover Controller 报红未正常启动，Cloudera 报告 Failover Controller 的进程状态为退出 在 Cloudera 的 Failover Controller 错误 ①： 在对应的宿主机上执行 hdfs zkfc -formatZK 后报错误 ②：

不可以，升级ios不能解决根本问题，ASA要想支持Failover 必须要有Security Plus license 或者更高级功能的license （license 需要向Cisco 购买）激活方式 ：全局模式下activation-key + license即可

我们介绍了 TiDB Operator 的 Controller Manager 的设计和实现，了解了各个 Controller 如何接受和处理变更。在这篇文章中，我们将讨论组件的 Controller 的实现。TiDBCluster Controller 负责了 TiDB 主要组件的生命周期管理，我们将以此为例， 介绍组件控制循环的编排设计。我们将会了解到完成 TiDB 集群的生命周期管理过程中，各种控制循环事件经过了怎样的编排，这些事件中又完成了哪些资源管理操作。在阅读时，大家了解这些工作的大致过程和定义即可，我们将在下一篇文章中具体介绍各个组件如何套用下面的范式。组件控制循环的调用在上一篇文章的代码介绍中，我们提到了 TiDBCluster controller 的 updateTidbCluster 函数，位于 pkg/controller/tidbcluster/tidb_cluster_control.go，它是 TiDB 组件生命周期管理的入口，调用了一系列生命周期管理函数。略去注释，我们可以发现 updateTidbCluster 函数依次调用了以下函数：c.reclaimPolicyManager.Sync(tc)c.orphanPodsCleaner.Clean(tc)c.discoveryManager.Reconcile(tc)c.ticdcMemberManager.Sync(tc)c.tiflashMemberManager.Sync(tc)c.pdMemberManager.Sync(tc)c.tikvMemberManager.Sync(tc)c.pumpMemberManager.Sync(tc)c.tidbMemberManager.Sync(tc)c.metaManager.Sync(tc)c.pvcCleaner.Clean(tc)c.pvcResizer.Resize(tc)c.tidbClusterStatusManager.Sync(tc)这些函数可以分为两类，一是 TiDB 组件的视角组织的控制循环实现，例如 PD，TiDB，TiKV，TiFlash，TiCDC，Pump，Discovery，另外一类是负责管理 TiDB 组件所使用的 Kubernetes 资源的管理以及其他组件外围的生命周期管理操作，例如 PV 的 ReclaimPolicy 的维护，OrphanPod 的清理，Kubernetes 资源的 Meta 信息维护，PVC 的清理和扩容，TiDBCluster 对象的状态管理等。TiDB 组件的生命周期管理过程TiDB 的主要组件控制循环的代码分布在 pkg/manager/member 目录下以 _member_manager.go 结尾的文件下，比如 pd_member_manager.go，这些文件又引用了诸如 _scaler.go，_upgrader.go 的文件，这些文件包含了扩缩容和升级相关功能的实现。从各个组件的 _member_manager.go 相关文件，我们可以提炼出以下通用实现：// Sync Serviceif err := m.syncServiceForTidbCluster(tc); err != nil { return err}// Sync Headless Serviceif err := m.syncHeadlessServiceForTidbCluster(tc); err != nil { return err}// Sync StatefulSetreturn syncStatefulSetForTidbCluster(tc)func syncStatefulSetForTidbCluster(tc *v1alpha1.TidbCluster) error { if err := m.syncTidbClusterStatus(tc, oldSet); err != nil { klog.Errorf("failed to sync TidbCluster: [%s/%s]"s status, error: %v", ns, tcName, err) } if tc.Spec.Paused { klog.V(4).Infof("tidb cluster %s/%s is paused, skip syncing for statefulset", tc.GetNamespace(), tc.GetName()) return nil } cm, err := m.syncConfigMap(tc, oldSet) newSet, err := getnewSetForTidbCluster(tc, cm) if err := m.scaler.Scale(tc, oldSet, newSet); err != nil { return err } if err := m.failover.Failover(tc); err != nil { return err } if err := m.upgrader.Upgrade(tc, oldSet, newSet); err != nil { return err } return UpdateStatefulSet(m.deps.StatefulSetControl, tc, newSet, oldSet)}登录后复制这段代码主要完成了同步 Service 和 同步 Statefulset 的工作，同步 Service 主要是为组件创建或同步 Service 资源，同步 Statefulset 具体包含了一下工作：同步组件的 Status;检查 TiDBCluster 是否停止暂停了同步;同步 ConfigMap;根据 TidbCluster 配置生成新的 Statefulset，并且对新 Statefulset 进行滚动更新，扩缩容，Failover 相关逻辑的处理;创建或者更新 Statefulset;组件的控制循环是对上面几项工作循环执行，使得组件保持最新状态。下面将介绍 TiDB Operator 中这几项工作具体需要完成哪些方面的工作。同步 Service一般 Service 的 Reconcile 在组件 Reconcile 开始部分，它负责创建和同步组件所使用的 Service，例如 cluster1-pd 和 cluster1-pd-peer。在控制循环函数中，会调用 getNewServiceForTidbCluster 函数，通过 Tidbcluster CR 中记录的信息创建一个新的 Service 的模板，如果 Service 不存在，直接创建 Service，否则，通过比对新老 Service Spec 是否一致，来决定是否要更新 Service 对象。TiDB 组件使用的 Service 中，包括了 Service 和 Headless Serivce，为组件提供了被访问的能力。当组件不需要知道是哪个实例正在与它通信，并且可以接受负载均衡方式的访问，则可以使用 Service 服务，例如 TiKV，TiDB 等组件访问 PD 时，就可以使用 Service 地址。当组件需要区分是那个 Pod 在提供服务时，则需要用 Pod DNS 进行通信，例如 TiKV 在启动时，会将自己的 Pod DNS 作为 Advertise Address 对外暴露，其他 Pod 可以通过这个 Pod DNS 访问到自己。同步 Status完成 Service 的同步后，组件接入了集群的网络，可以在集群内访问和被访问。控制循环会进入 syncStatefulSetForTidbCluster，开始对 Statefulset 进行 Reconcile，首先是使用 syncTidbClusterStatus 对组件的 Status 信息进行同步，后续的扩缩容、Failover、升级等操作会依赖 Status 中的信息进行决策。同步 Status 是 TiDB Operator 比较关键的操作，它需要同步 Kubernetes 各个组件的信息和 TiDB 的集群内部信息，例如在 Kubernetes 方面，在这一操作中会同步集群的副本数量，更新状态，镜像版本等信息，检查 Statefulset 是否处于更新状态。在 TiDB 集群信息方面，TiDB Operator 还需要将 TiDB 集群内部的信息从 PD 中同步下来。例如 PD 的成员信息，TiKV 的存储信息，TiDB 的成员信息等，TiDB 集群的健康检查的操作便是在更新 Status 这一操作内完成。检查 TiDBCluster 是否暂停同步更新完状态后，会通过 tc.Spec.Paused 判断集群是否处于暂停同步状态，如果暂停同步，则会跳过下面更新 Statefulset 的操作。同步 ConfigMap在同步完 Status 之后，syncConfigMap 函数会更新 ConfigMap，ConfigMap 一般包括了组件的配置文件和启动脚本。配置文件是通过 YAML 中 Spec 的 Config 项提取而来，目前支持 TOML 透传和 YAML 转换，并且推荐 TOML 格式。启动脚本则包含了获取组件所需的启动参数，然后用获取好的启动参数启动组件进程。在 TiDB Operator 中，当组件启动时需要向 TiDB Operator 获取启动参数时，TiDB Operator 侧的信息处理会放到 discovery 组件完成。如 PD 获取参数用于决定初始化还是加入某个节点，就会使用 wget 访问 discovery 拿到自己需要的参数。这种在启动脚本中获取参数的方法，避免了更新 Statefulset 过程中引起的非预期滚动更新，对线上业务造成影响。生成新 StatefulsetgetNewPDSetForTidbCluster 函数会得到一个新的 Statefulset 的模板，它包含了对刚才生成的 Service，ConfigMap 的引用，并且根据最新的 Status 和 Spec 生成其他项，例如 env，container，volume 等，这个新的 Statefulset 还需要送到下面 3 个流程进行滚动更新，扩缩容，Failover 方面的加工，最后将这个新生成的 Statefulset 会被送到 UpdateStatefulSet 函数处理，判断其是否需要实际更新到组件对应的 Statefulset。新 Statefulset 的加工(一): 滚动更新m.upgrader.Upgrade 函数负责滚动更新相关操作，主要更新 Statefulset 中 UpgradeStrategy.Type 和 UpgradeStrategy.Partition，滚动更新是借助 Statefulset 的 RollingUpdate 策略实现的。组件 Reconcile 会设置 Statefulset 的升级策略为滚动更新，即组件 Statefulset 的 UpgradeStrategy.Type 设置为 RollingUpdate 。在 Kubernetes 的 Statefulset 使用中，可以通过配置 UpgradeStrategy.Partition 控制滚动更新的进度，即 Statefulset 只会更新序号大于或等于 partition 的值，并且未被更新的 Pod。通过这一机制就可以实现每个 Pod 在正常对外服务后才继续滚动更新。在非升级状态或者升级的启动阶段，组件的 Reconcile 会将 Statefulset 的 UpgradeStrategy.Partition 设置为 Statefulset 中最大的 Pod 序号，防止有 Pod 更新。在开始更新后，当一个 Pod 更新，并且重启后对外提供服务，例如 TiKV 的 Store 状态变为 Up，TiDB 的 Member 状态为 healthy，满足这样的条件的 Pod 才被视为升级成功，然后调小 Partition 的值进行下一 Pod 的更新。新 Statefulset 的加工(二): 扩缩容m.scaler.Scale 函数负责扩缩容相关操作，主要是更新 Statefulset 中组件的 Replicas。Scale 遵循逐个扩缩容的原则，每次扩缩容的跨度为 1。Scale 函数会将 TiDBCluster 中指定的组件 Replicas 数，如 tc.Spec.PD.Replicas，与现有比较，先判断是扩容需求还是缩容需求，然后完成一个步长的扩缩容的操作，再进入下一次组件 Reconcile，通过多次 Reconcile 完成所有的扩缩容需求。在扩缩容的过程中，会涉及到 PD 转移 Leader，TiKV 删除 Store 等使用 PD API 的操作，组件 Reconcile 过程中会使用 PD API 完成上述操作，并且判断操作是否成功，再逐步进行下一次扩缩容。新 Statefulset 的加工(三): Failoverm.failover.Failover 函数负责容灾相关的操作，包括发现和记录灾难状态，恢复灾难状态等，在部署 TiDB Operator 时配置打开 AutoFailover 后，当发现有 Failure 的组件时记录相关信息到 FailureStores 或者 FailureMembers 这样的状态存储的键值，并启动一个新的组件 Pod 用于承担这个 Pod 的工作负载。当原 Pod 恢复工作后，通过修改 Statefulset 的 Replicas 数量，将用于容灾时分担工作负载的 Pod 进行缩容操作。但是在 TiKV/TiFlash 的容灾逻辑中，自动缩容容灾过程中的 Pod 不是默认操作，需要设置 spec.tikv.recoverFailover: true 才会对新启动的 Pod 缩容。使用新 Statefulset 进行更新在同步 Statefulset 的最后阶段，已经完成了新 Statefulset 的生成，这时候会进入 UpdateStatefulSet 函数，这一函数中主要比对新的 Statefulset 和现有 StatefulSet 差异，如果不一致，则进行 Statefulset 的实际更新。另外，这一函数还需要检查是否有没有被管理的 Statefulset，这部分主要是旧版本使用 Helm Chart 部署的 TiDB，需要将这些 Statefulset 纳入 TiDB Operator 的管理，给他们添加依赖标记。完成上述操作后，TiDBCluster CR 的 Status 更新到最新，相关 Service，ConfigMap 被创建，生成了新的 Statefulset，并且满足了滚动更新，扩缩容，Failover 的工作。组件的 Reconcile 周而复始，监控着组件的生命周期状态，响应生命周期状态改变和用户输入改变，使得集群在符合预期的状态下正常运行。其他生命周期维护工作除了 TiDB 主要组件的视角之外，还有一些运维操作被编排到了下面的函数实现中，他们分别负责了以下工作：Discovery，用于 PD 启动参数的配置和 TiDB Dashboard Proxy，Discovery 的存在，可以提供一些动态信息供组件索取，避免了修改 ConfigMap 导致 Pod 滚动更新。Reclaim PolicyManager，用于同步 tc.Spec.PVReclaimPolicy 的配置，默认配置下会将PV 的 Reclaim Policy 设置为 Retain，降低数据丢失的风险。OrphanPodCleaner，用于在 PVC 创建失败的时候清除 Pod，让 Statefulset Controller 重试 Pod 和对应 PVC 的创建。PVC Cleaner 用于 PVC 相关资源清理，清理被标记可以删除的 PVC。PVC Resizer 用于 PVC 的扩容，在云上使用时可以通过修改 TidbCluster 中的 Storage 相关配置修改 PVC 的大小。Meta Manager 用于同步 StoreIDLabel，MemberIDLabel，NamespaceLabel 等信息到 Pod，PVC，PV 的 label 上。TiDBCluster Status Manager 用于同步 TidbMonitor 和 TiDB Dashboard 相关信息。小结这篇文章介绍了 TiDBCluster 组件的控制循环逻辑的设计，试图让大家了解，当 TiDBCluster Controller 循环触发各个组件的 Reconcile 函数时，组件 Reconcile 函数是按照怎样的流程巡检组件的相关资源，用户预期的状态，是如何通过 Reconcile 函数，变成实际运行的组件。TiDB Operator 中的控制循环都大致符合以上的设计逻辑，在后面的文章中，我们会具体介绍每个组件是如何套用上面的设计逻辑，实现组件的生命周期管理。如果有什么好的想法，欢迎通过 #sig-k8s 或 pingcap/tidb-operator 参与 TiDB Operator 社区交流。数据库分布式激光投影和LED投影的区别，哪个更好？精选推荐广告TiDB Operator 源码阅读 (四) 组件的控制循环218阅读·0评论·0点赞2021年6月30日TiDB、mysql修改系统变量/常用语句（杀死process中的进程）1425阅读·0评论·0点赞2019年12月5日TiDB Operator 架构67阅读·0评论·1点赞2022年7月11日TiDB 的正确使用姿势1251阅读·0评论·1点赞2020年2月27日TiDB 优化方案和常见问题2820阅读·0评论·1点赞2020年5月24日tidb使用坑记录4097阅读·0评论·1点赞2018年2月22日抑郁自测题：35分以上是重度抑郁，测测你的抑郁有多深？国际专业抑郁测试广告tidb 架构 ~Tidb学习系列(4)210阅读·0评论·0点赞2018年11月1日TiDB SQL开发基础——增删改查3252阅读·0评论·0点赞2018年7月19日TiDB 官方设计文档翻译（一）1.5W阅读·0评论·3点赞2017年3月5日mysql 游标循环_MySQL 游标 循环1456阅读·0评论·1点赞2021年1月18日TiDB Operator 需要的 RBAC 规则53阅读·0评论·1点赞2022年7月12日TiDB 最佳实践系列（五）Java 数据库应用开发指南2752阅读·0评论·1点赞2019年11月7日TiDB 源码阅读系列文章（十六）INSERT 语句详解189阅读·0评论·0点赞2018年8月20日批量添加数据到数据库1413阅读·0评论·0点赞2018年5月28日tidb源码编译安装，从入门到差点放弃1267阅读·2评论·0点赞2020年8月25日TiDB 内核-源码解读 Point_Get 点查的一生366阅读·0评论·3点赞2022年5月12日Kubernetes资源编排系列之四: CRD+Operator篇281阅读·0评论·1点赞2022年8月8日去首页看看更多热门内容

你的许可证文件没有放好吧

背景 随着互联网的发展，应用服务中的定时任务数量日益增加，常规的垂直应用架构已无法应对，分布式服务架构势在必行。同时，也迫切需要一个分布式任务调度系统来管理分布式服务中的定时任务。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，在该应用中的定时任务如果不多还好，但是一旦比较多，则意味着每次更改一个定时任务的执行时间，就需要重新部署一遍整个应用，导致整个应用停滞一段时间。 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分为互不相干的几个应用来提升效率。此时，相应的任务也会被垂直拆分，每次更改任务带来的影响相应减少。 分布式服务架构 当垂直应用越来越多，应用之间可能会出现不可避免的交互，此时，将核心业务抽取出来，形成单独的服务，各式各样的服务逐渐形成稳定的服务中心，使得前端应用能更快地响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架是关键，同时，由于服务独立，则一般能做到定时任务独立的情况，因此，任务的更改对于整体系统的影响小之又小。 分布式任务调度 在分布式服务架构的基础上，由于独立业务的数量可能很多，此时如果定时任务单独在该服务中实现，很可能会出现难以管理的情况，且避免不了定时任务更改导致的业务重启，因此，一个独立的分布式任务调度系统是很必要的，可以用来全局统筹管理所有的定时任务，同时，将任务的配置单独抽离出来作为该分布式任务调度系统的功能，就能做到定时任务的更改不影响任何业务，也不影响整个系统。 架构设计 设计思想 以Dubbo核心，将调度单独抽象出来，成为一个调度中心，调度中心本身不承担实现任何业务逻辑，只是单纯依据调度配置来发起调度请求 将任务抽象成为ExecutorService，由任务执行者来实现具体的任务，并且负责接收调度请求并执行，这样设计可以将任务与调度中心完全解耦，提高整个系统的扩展性，方便接入 将调度中心对任务执行者的一些调用操作提取出来，形成一个单独的管理控制台，可以用来查看任务执行情况，同时该管理控制台通过H5实现，并提供对外Restful API，方便扩展与接入 通过各种中间件，实现一些必须的操作，例如告警，监控，日志收集统计等操作，完全对整个系统安全性，稳定性的保障 调度中心集群通过Zookeeper存储每个Schedular的一致性HashCode，以此来分配Job与Schedular之间的关系：新增的Job将会通过每个Schedular的一致性HashCode获取其对应的Job数，依据Job数的大小以及Schedular的相关属性来计算每个Schedular的权重，根据权重的大小来确定当前新增的Job应该被分配到哪个Schedular上。 当新增Schedular之后，该新增的Schedular的Job正常为0，因此，正常状态下，该新增的Schedular的权重会比较大。 同时，调度中心通过Zookeeper对Schedular实现主备切换，确保系统稳定性 系统组成 Schedular 基于Quartz实现调度，提供对执行者操作的接口，用于操作任务调度配置，调度触发等操作;自身不参与任务逻辑的实现，不会受限于任务 执行者 负责接收调度中心发起的调度请求，实现相应业务逻辑，完成任务执行，同时会对任务逻辑进行切面处理，记录相应日志并在任务结束后发送给调度中心 管理控制台 管理控制台负责展示任务状态，执行情况，任务执行日志等报表数据，同时可以通过管理控制台配置新增任务，操作任务的状态，暂停/恢复等;另外，提供对外Restful API与H5的接入 Dubbo Monitor 实时监控调度中心接口调用情况，统计调度频次，成功失败，QPS等，能通过这些报表数据来优化任务调度，优化系统 ELK 通过ELK（ElasticSearch+Logstash+Kibana）来收集调度中心以及各执行机的执行日志，并加以分析统计，形成报表，可以方便提供观察 Alarm 报警系统，通过Chronograf控制台配置告警规则，在出现问题时第一时间通过Kapacitor进行邮件与短信报警，可以有效提高错误提示的及时性并且降低错误发生到错误解决过程中消耗的时间，降低生产环境造成的损失，告警数据通过业务仪表盘获取。例如：可以配置线上机器的cpu当前使用率，设置阀值50%，策略为超过设置阀值时短信告警，此时当线上某台机器cpu超过50%时，即会发送短信告警 业务仪表盘 通过打点的方式，来实时收集接口监控数据，通过logstash传输到kafka，通过kafka再分发到jstorm进行处理，处理完之后再存储到influxdb，形成业务仪表盘，最后通过Grafana控制台产生监控报表 配置中心 整个系统各服务，通过配置中心统一管理相应配置，形成分布式配置管理机制，方便系统内各服务的配置一致性以及准确性 在配置完之后，就可以实现自己的任务逻辑了 接入之后，可以通过日志管理控制台线上实时查看任务执行状态 另外，由于有告警系统，在任务执行异常时，会产生告警邮件与短信，实时发送，告知任务接入者与相应研发人员 配置中心属性配置 特性 支持动态暂停/恢复任务 任务状态停止时，任务将不再被触发，若任务在执行过程中被暂停，则正在执行的任务不会被阻塞（由于任务执行结果状态中存在超时失败状态，因此如果点击暂停按钮时阻塞了当前正在执行的任务，会使当前任务的执行状态变为超时，不符合超时状态真正的意义），会延迟停止，即等到当前任务执行完再真正停止任务 调度中心基于Quartz实现，通过Zookeeper实现主备隔离，保证调度中心HA 当活跃节点宕机，冷备节点就会载入所有活跃节点中正在调度状态的任务，成为新的活跃节点，保证任务调度的准确执行 执行机支持集群部署，任务分布式执行，通过调度中心统一调度 执行机负载均衡，默认根据任务在某个执行机上的执行次数计算执行机调度权重，按照权重来选择本次任务调度分发给哪台执行机，实现负载均衡，可手动更改执行机选择策略 执行机集群方式, failover,failfast,failsafe,failback,forking，默认为failover(故障切换)，调用失败时，重试其他服务器;failfast(快速失败)，只会发起一次调用，不会重试，失败立即报错;failsafe(失败安全)，出现异常时，直接忽略;failback(失败恢复)，调用失败时，定时重发，直到成功，重启会丢失; forking，并行调用多个执行机，只要一个成功即返回 分片任务，支持任务分片，通过参数发送给任务执行机，执行机可以通过判断参数来进行分片作业的开发，同时支持动态分片，以分片参数和执行机为纬度进行分片，支持动态扩容执行机以及分片参数 例如，某张订单表按照订单ID来进行简单纬度分片，且以取模3来进行分片，则可以设置三个分片参数，(0，1，2)，执行机在通过context拿到其中的一个分片参数之后可以对该分片参数做判断，来做具体的数据操作，例如当拿到的分片参数为0时，则对于0相应的分片做数据查询操作，依次类推 再例如，某张订单表按照订单ID和Status来进行二维分片，ID取模以3来进行分片，状态以成功，失败两种状态来进行分片，此时就可以设置6个分片参数，({‘id":0,"status":0},{‘id":1,"status":0},{‘id":2,"status":0},{‘id":0,"status":1},{‘id":1,"status":1},{‘id":2,"status":1}),执行机在通过context拿到其中的一个分片参数之后，就可以对其json参数进行判断，来实现分片操作 任务执行一致性，每次任务只会被一个执行机所执行;对于分片任务，在执行机集群部署时，一次任务调度将会广播触发对应集群中相应数量的执行器执行一次任务，同时传递分片参数，可根据分片参数开发分片任务。 当分片参数大于执行器数量时，将会按照执行器路由策略，使得当前分片任务的某个或者某几个执行机执行多个分片的任务 例如：当前分片任务分片参数为(a,b,c),当前任务执行机有3台(A,B,C)时，则会均匀随机得将分片参数发送给某一台执行机，且三台执行机一次只接收一个分片参数，做一次任务处理，即(a->A,b->B,c->C)|(a->A,b->C,c->B)|(a->B,b->A,c->C)|(a->B,b->C,c->A)|(a->C,b->A,c->B) |(a->C,b->B,c->A)； 当任务执行机只有2台(A,B)时，每次任务调度时，某台执行机会收到两个分片参数，并分别处理这两个分片参数,即(a->A,b->B,c->A)|(a->A,b->B,c->B)|(a->B,b->A,c->A)|(a->B,b->A,c->B)； 而当任务执行机大于分片参数个数，为4台(A,B,C,D)时，(a->A,b->B,c->C)|(a->A,b->C,c->D)|(a->A,b->D,c->B)| (a->B,b->C,c->D)|(a->B,b->D,c->A)|(a->B,b->A,c->C)|(a->C,b->A,c->B)|(a->C,b->B,c->D)| (a->C,b->D,c->A)|(a->D,b->A,c->B)|(a->D,b->B,c->C)|(a->D,b->C,c->A)，而统计下来，不管是执行机数目大于或者等于或者小于分片参数数目，被分发给执行机的分片参数始终是保持一致的（每台执行机接收到的总的分片参数是均匀的） 告警系统，系统接入内部告警系统，任务失败时支持邮件，短信，钉钉，电话等告警 弹性扩容缩容，调度中心将会实时探测任务执行机，因此一旦有执行机上线或者下线，都将会被探测到，而如果未被调度中心探测到，则可以进行手动探测执行机，而在探测到执行机之后，下次调度将会重新分配任务 任务依赖，支持配置任务依赖关系，当父任务在执行完成之后会自动触发子任务的执行例如：有两个任务，分别为A和B，而B的执行条件为确认A任务执行完，B才能执行，否则，B任务不执行，此时的依赖关系就是B任务依赖A任务，此时在A任务配置完之后，设置B任务为依赖任务，而依赖关系则是A；又例如有6个任务，分别是A1,A2,A3,A4,A5,B，而B任务的执行需要确保A1-5这5个任务都执行完，B任务才执行，此时，B的依赖关系就是B任务依赖于A1-5，此时在配置完A1-5这5个任务之后再设置B为依赖任务，依赖关系则是A1-5 支持运行时查看任务执行情况，任务数量，调用次数，执行器数量等统计信息异常执行恢复机制，有时会遇到不可控情况，即执行机在执行后的执行结果因为网络断开等不可控因素导致不能发送给调度中心，此时能通过异常执行恢复机制临时记录，在下次执行机正常启动时重试发送给调度中心调度手动触发手动执行，特殊需求下，可能会要求调度可以手动执行，例如调度任务失败之后可能需要手动执行一次调度来补偿 并行/串行策略，当定时时间远大于任务执行时间时，可以使用并行策略，任务异步调用执行，提高任务调度精确度;当任务执行时间可能大于定时时间，却需要任务按照某个定时规则定时调度时，可以使用串行策略，调度中心调度的当前任务的上一次触发，如果没有执行完，则当前执行机的下一次定时时间点时不会被触发，当且仅当任务执行结束，以防止某些持续性定时任务的时间不确定性导致异步触发时的数据混乱的情况发生，例如：某一任务的定时时间为10秒钟，但是任务本身可能会出现执行超过10秒的情况，而超过时，如果出现两个时间点的任务并行执行时会出现数据混乱的情况，此时就可以使用串行策略，确保当前执行机上一个任务未执行完，不会触发新的执行 支持调度接口数据监控，产生监控报表，便于观测。 总结 对于互联网公司来说，时间就是金钱，效率决定一切。本系统在接入到8月初将近3个月的时间内，表现不凡，调度了约100万次，给公司内部各服务实现任务调度提供了便利。 原文

都是什么时代了，还用vista啊，赶快换吧

013 Hadoop High Availability – Namenode Automatic Failover Before Hadoop 2.0 that is Hadoop 1.0 faced a single point of failure (SPOF) in NameNode. This means if the NameNode failed the entire system would not function and manual intervention was necessary to bring the Hadoop cluster up with the help of secondary NameNode which resulted in overall downtime. With Hadoop 2.0 we had single standby node to facilitate automatic failover and with Hadoop 3.0 which supports multiple standby nodes, the system has become even more highly available. In this tutorial, we will talk about Hadoop high availability. We will look at various types of failover and discuss in detail how the components of Zookeeper provide for automatic failover. 在 Hadoop 2.0 之前，Hadoop 1.0 在 NameNode 中面临单点故障 (SPOF).这意味着，如果 NameNode 出现故障，整个系统将无法运行，需要手动干预 Hadoop 集群 在二级 NameNode 的帮助下，导致了整体停机.借助 Hadoop 2.0，我们有了单个备用节点，以方便自动故障切换; 借助支持多个备用节点的 Hadoop 3.0，系统变得更加可用.在本教程中，我们将讨论 Hadoop 高可用性.我们将研究各种类型的故障切换，并详细讨论 动物园管理员组件 提供自动故障切换. Hadoop High Availability – Automatic Failover With Hadoop 2.0, we have support for multiple NameNodes and with Hadoop 3.0 we have standby nodes. This overcomes the SPOF (Single Point Of Failure) issue using an extra NameNode (Passive Standby NameNode) for automatic failover. This is the high availability in Hadoop. 借助 Hadoop 2.0，我们支持多个名称节点，借助 Hadoop 3.0，我们拥有备用节点.这克服了使用额外的 NameNode (被动备用 NameNode) 进行自动故障切换的 SPOF (单点故障) 问题.这是 Hadoop 中的高可用性. Failover is a process in which the system transfers control to a secondary system in an event of failure. 故障切换是指在发生故障时，系统将控制转移到辅助系统的过程. There are two types of failover: 故障切换有两种类型: Automatic failover in Hadoop adds up below components to a Hadoop HDFS deployment: Hadoop 中的自动故障切换将以下组件添加到 Hadoop HDFS 部署中: Zookeeper quorum is a centralized service for maintaining small amounts of data for coordination, configuration, and naming. It provides group services and synchronization. It keeps the client informed about changes in data and track client failures. Implementation of automatic HDFS failover relies on Zookeeper for: Zookeeper 是用于维护少量数据以进行协调、配置和命名的集中服务.它提供组服务和同步.它让客户了解数据的变化，并跟踪客户故障.执行自动 HDFS 失败转移功能依赖于管理员的: ZKFC is a client of Zookeeper that monitors and manages the namenode status. So, each of the machines which run namenode service also runs a ZKFC. ZKFC 是一个客户管理员监督和管理、复制指令的情况.因此，运行 namenode 服务的每台机器也都运行 ZKFC. ZKFC handles: ZKFC 手柄: **Health Monitoring – **ZKFC periodically pings the active NameNode with Health check command and if the NameNode doesn"t respond it in time it will mark it as unhealthy. This may happen because the NameNode might be crashed or frozen. 健康监测- ZKFC 定期用健康检查命令 ping 活跃的 NameNode，如果 NameNode 没有及时响应，它会将其标记为不健康.这可能是因为 NameNode 可能会崩溃或冻结. Zookeeper Session Management – If the local NameNode is healthy it keeps a session open in the Zookeeper. If this local NameNode is active, it holds a special lock znode . If the session expires then this lock will delete automatically. 会话管理- 如果本地名称节点是健康的，它会在 Zookeeper 中保持会话打开.如果这个本地名称节点是活动的，它会持有一个特殊的锁 Znode .如果会话过期，则此锁将自动删除. Zookeeper-based Election – If there is a situation where local NameNode is healthy and ZKFC gets to know that none of the other nodes currently holds the znode lock, the ZKFC itself will try to acquire that lock. If it succeeds in this task then it has won the election and becomes responsible for running a failover. The failover is similar to manual failover; first, the previously active node is fenced if required to do so and then the local node becomes the active node. 动物园管理员的选举 如果本地 NameNode 健康，ZKFC 知道目前没有其他节点持有 znode 锁，ZKFC 本身将尝试获得该锁.如果它在这个任务中成功，那么它就赢得了选举，并负责运行故障切换.故障切换类似于手动故障切换; 首先，如果需要，以前的活动节点会被隔离，然后本地节点会成为活动节点. Hence, in this Hadoop High Availability article, we saw Zookeeper daemons configure to run on three or five nodes. Since Zookeeper does not have high resource requirement it could be run on the same node as the HDFS Namenode or standby Namenode. Many operators choose to deploy third Zookeeper process on the same node as the YARN Resource Manager. So, it is advised to keep Zookeeper data separate from HDFS metadata i.e. on different disks as it will give the best performance and isolation. 因此，在这个 Hadoop 高可用性 文章中，我们看到 Zookeeper 守护进程被配置为在三到五个节点上运行.因为管理员没有所需的它可以运行在相同的节点为 HDFS 、复制指令或待机、复制指令.许多操作员选择在与 YARN 资源管理器相同的节点上部署第三个 Zookeeper 进程.因此，建议将 Zookeeper 数据与 HDFS 元数据分开，即在不同的磁盘上，因为它将提供最佳的性能和隔离. You must check the latest Hadoop Interview Questions for your upcoming interview. 你必须检查一下 最新 Hadoop 面试题: 为你即将到来的面试. Still, if any doubt regarding Hadoop High Availability, ask in the comments. We will definitely get back to you. 尽管如此，如果对 Hadoop 的高可用性有任何疑问，请在评论中提问.我们一定会给你回复的 https://data-flair.training/blogs/hadoop-high-availability

从做一个系统

通俗的说索引是用来提高查询效率，不需要通过扫描全部表记录，而直接使用索引快速定位需要查询的值。

使用DHCP正常获取地址的过程中使用的是以下4种报文：（1）客户端广播DHCP发现（DHCP Discovery）（2）服务器回应DHCP响应（DHCP Offer）（3）客户端广播DHCP请求（DHCP Request）（4）服务器回应DHCP确认（DHCP ACK）其实还有其他类型的报文，客户端发现分配的IP地址已经被占用时，发送DHCP Decline，通知服务器IP地址已被占用，要求重新分配。客户端可以主动释放IP地址，DHCP Release。如果客户端移动到了另一个IP地址不同的网络，并向服务器申请续租时，服务器发现客户端IP地址错误，发送DHCP NAK通知客户端重新申请IP地址。延展阅读：【DHCP简介】DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是一个局域网的网络协议，使用UDP协议工作， 主要有两个用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段，在RFC 2131中有详细的描述。DHCP有3个端口，其中UDP67和UDP68为正常的DHCP服务端口，分别作为DHCP Server和DHCP Client的服务端口；546号端口用于DHCPv6 Client，而不用于DHCPv4，是为DHCP failover服务，这是需要特别开启的服务，DHCP failover是用来做“双机热备”的。【功能概述】DHCP协议采用客户端/服务器模型，主机地址的动态分配任务由网络主机驱动。当DHCP服务器接收到来自网络主机申请地址的信息时，才会向网络主机发送相关的地址配置等信息，以实现网络主机地址信息的动态配置。DHCP具有以下功能：1、 保证任何IP地址在同一时刻只能由一台DHCP客户机所使用。2、DHCP应当可以给用户分配永久固定的IP地址。3、DHCP应当可以同用其他方法获得IP地址的主机共存（如手工配置IP地址的主机）。4、DHCP服务器应当向现有的BOOTP客户端提供服务。

你后来怎么解决了？

前期准备1.修改Linux主机名，每台都得配置vim /etc/sysconfig/networkNETWORKING=yesHOSTNAME=hadoop-server12.修改IP /etc/sysconfig/network-scripts/ifcfg-eth03.修改主机名和IP的映射关系vim /etc/hosts192.168.146.181 hadoop-server1192.168.146.182 hadoop-server2192.168.146.183 hadoop-server3192.168.146.184 hadoop-server4192.168.146.185 hadoop-server5######注意######如果你们公司是租用的服务器或是使用的云主机（如华为用主机、阿里云主机等）/etc/hosts里面要配置的是内网IP地址和主机名的映射关系4.关闭防火墙 #查看防火墙状态service iptables status#关闭防火墙service iptables stop#查看防火墙开机启动状态chkconfig iptables --list#关闭防火墙开机启动chkconfig iptables off前4步用root用户操作，操作完后重启机器5..sh免登陆hadoop用户操作#生成ssh免登陆密钥#进入到我的home目录cd ~/.sshssh-keygen -t rsa （四个回车）执行完这个命令后，会生成两个文件id_rsa（私钥）、id_rsa.pub（公钥）将公钥拷贝到要免密登陆的目标机器上ssh-copy-id hadoop-server26.安装JDK，配置环境变量等root用户操作vim /etc/proflieexport JAVA_HOME=/usr/java/jdk1.7.0_65export HADOOP_HOME=/itcast/hadoop-2.4.1export PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbinsource /etc/profile集群规划：主机名 IP 安装软件 运行进程hadoop-server1 192.168.146.181:jdk、hadoopnamenode resourcemanageDFSZKFailoverController(zkfc)hadoop-server2 192.168.146.182:jdk、hadoopnamenode resourcemanageDFSZKFailoverController(zkfc)hadoop-server3 192.168.146.183:jdk、hadoop、zookeeperdatanode nodemanagejournalnode QuorumPeerMainhadoop-server4 192.168.146.184:jdk、hadoop、zookeeperdatanode nodemanagejournalnode QuorumPeerMainhadoop-server5 192.168.146.185:jdk、hadoop、zookeeperdatanode nodemanagejournalnode QuorumPeerMain安装步骤：1.安装配置zooekeeper集群（在hadoop-server3上）1.1解压tar -zxvf zookeeper-3.4.5.tar.gz -C /home/hadoop/app/1.2修改配置cd /home/hadoop/app/zookeeper-3.4.5/conf/cp zoo_sample.cfg zoo.cfgvim zoo.cfg修改：dataDir=/home/hadoop/app/zookeeper-3.4.5/data在最后添加：server.1=hadoop-server3:2888:3888server.2=hadoop-server4:2888:3888server.3=hadoop-server5:2888:3888保存退出然后创建一个tmp文件夹mkdir /home/hadoop/app/zookeeper-3.4.5/data再创建一个空文件touch /home/hadoop/app/zookeeper-3.4.5/data/myid最后向该文件写入IDecho 1 > /home/hadoop/app/zookeeper-3.4.5/data/myid1.3将配置好的zookeeper拷贝到其他节点scp -r /home/hadoop/app/zookeeper-3.4.5/ weekend06:/home/hadoop/app/scp -r /home/hadoop/app/zookeeper-3.4.5/ weekend07:/home/hadoop/app/注意：修改hadoop-server4、hadoop-server5对应/home/hadoop/app/zookeeper-3.4.5/data/myid内容hadoop-server4：echo 2 > /home/hadoop/app/zookeeper-3.4.5/data/myidhadoop-server5：echo 3 > /home/hadoop/app/zookeeper-3.4.5/data/myid2.安装配置hadoop集群（在hadoop-server1上操作）2.1解压tar -zxvf hadoop-2.4.1.tar.gz -C /weekend/2.2配置HDFS（hadoop2.0所有的配置文件都在$HADOOP_HOME/etc/hadoop目录下）#将hadoop添加到环境变量中vim /etc/profileexport JAVA_HOME=/hadoop/home/app/jdk1.7.0_55export HADOOP_HOME=/home/hadoop/app/hadoop-2.4.1export PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin#hadoop2.0的配置文件全部在$HADOOP_HOME/etc/hadoop下cd /home/hadoop/app/hadoop-2.4.1/etc/hadoop2.2.1修改hadoo-env.shexport JAVA_HOME=/home/hadoop/app/jdk1.7.0_552.2.2修改core-site.xml<configuration><!-- 指定hdfs的nameservice为ns1 --><property><name>fs.defaultFS</name><value>hdfs://ns1/</value></property><!-- 指定hadoop临时目录 --><property><name>hadoop.tmp.dir</name><value>/home/hadoop/app/hadoop-2.4.1/tmp</value></property><!-- 指定zookeeper地址 --><property><name>ha.zookeeper.quorum</name><value>hadoop-server3:2181,hadoop-server3:2181,hadoop-server3:2181</value></property></configuration>2.2.3修改hdfs-site.xml<configuration><!--指定hdfs的nameservice为ns1，需要和core-site.xml中的保持一致 --><property><name>dfs.nameservices</name><value>ns1</value></property><!-- ns1下面有两个NameNode，分别是nn1，nn2 --><property><name>dfs.ha.namenodes.ns1</name><value>nn1,nn2</value></property><!-- nn1的RPC通信地址 --><property><name>dfs.namenode.rpc-address.ns1.nn1</name><value>hadoop-server1:9000</value></property><!-- nn1的http通信地址 --><property><name>dfs.namenode.http-address.ns1.nn1</name><value>hadoop-server1:50070</value></property><!-- nn2的RPC通信地址 --><property><name>dfs.namenode.rpc-address.ns1.nn2</name><value>weekend02:9000</value></property><!-- nn2的http通信地址 --><property><name>dfs.namenode.http-address.ns1.nn2</name><value>hadoop-server2:50070</value></property><!-- 指定NameNode的元数据在JournalNode上的存放位置 --><property><name>dfs.namenode.shared.edits.dir</name><value>qjournal://hadoop-server3:8485;hadoop-server4:8485;hadoop-server5:8485/ns1</value></property><!-- 指定JournalNode在本地磁盘存放数据的位置 --><property><name>dfs.journalnode.edits.dir</name><value>/home/hadoop/app/hadoop-2.4.1/journaldata</value></property><!-- 开启NameNode失败自动切换 --><property><name>dfs.ha.automatic-failover.enabled</name><value>true</value></property><!-- 配置失败自动切换实现方式 --><property><name>dfs.client.failover.proxy.provider.ns1</name><value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value></property><!-- 配置隔离机制方法，多个机制用换行分割，即每个机制暂用一行--><property><name>dfs.ha.fencing.methods</name><value>sshfenceshell(/bin/true)</value></property><!-- 使用sshfence隔离机制时需要ssh免登陆 --><property><name>dfs.ha.fencing.ssh.private-key-files</name><value>/home/hadoop/.ssh/id_rsa</value></property><!-- 配置sshfence隔离机制超时时间 --><property><name>dfs.ha.fencing.ssh.connect-timeout</name><value>30000</value></property></configuration>2.2.4修改mapred-site.xml<configuration><!-- 指定mr框架为yarn方式 --><property><name>mapreduce.framework.name</name><value>yarn</value></property></configuration>2.2.5修改yarn-site.xml<configuration><!-- 开启RM高可用 --><property> <name>yarn.resourcemanager.ha.enabled</name> <value>true</value></property><!-- 指定RM的cluster id --><property> <name>yarn.resourcemanager.cluster-id</name> <value>yrc</value></property><!-- 指定RM的名字 --><property> <name>yarn.resourcemanager.ha.rm-ids</name> <value>rm1,rm2</value></property><!-- 分别指定RM的地址 --><property> <name>yarn.resourcemanager.hostname.rm1</name> <value>hadoop-server1</value></property><property> <name>yarn.resourcemanager.hostname.rm2</name> <value>hadoop-server2</value></property><!-- 指定zk集群地址 --><property> <name>yarn.resourcemanager.zk-address</name> <value>hadoop-server3:2181,hadoop-server4:2181,hadoop-server5:2181</value></property><property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value></property></configuration>2.2.6修改slaves(slaves是指定子节点的位置)hadoop-server3hadoop-server4hadoop-server5

　　DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是一个局域网的网络协议，使用UDP协议工作，主要有两个用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段，在RFC 2131中有详细的描述。DHCP有3个端口，其中UDP67和UDP68为正常的DHCP服务端口，分别作为DHCP Server和DHCP Client的服务端口；546号端口用于DHCPv6 Client，而不用于DHCPv4，是为DHCP failover服务，这是需要特别开启的服务，DHCP failover是用来做“双机热备”的。　　下面开始配置DHCP服务器：　　步骤以及方法：　　1.打开主机，在windows sever 2003 桌面上单击开始选择管理您的服务器并点击。　　　　2.在管理您的服务器页面选择添加或删除角色。　　3.在预备步骤页面点击下一步。　　4.在服务器角色页面选择DHCP服务器，点击下一步。　　5.在选择总结页面选择下一步。　　这是调取安装文件，并弹出一个新建作用域向导页面点击下一步。　　　　6.在作用域名页面填入想取得作用域名称，这里我给它取名：DHCP并点击下一步。　　　　7.　在IP地址范围内填入起始ip地址和结束的IP地址，下面的长度和子网掩码系统会自动填上，如果是变长子网则需要自己修改。起始和结束的IP地址是指想分配的ip地址段。这里我们给它范围为192.168.2.10-192.168.2.20，并点击下一步。　　　　8.在添加排除页面填入想排除的IP地址，比如说想保留哪个IP地址就把该地址填入进去则服务器就不会分配给客户端主机了。也可以填入一个排除ip段。我们这里保留192.168.2.15.排除这个ip我想保留它，填入后点击添加。并点击下一步。（这里要注意的是排除的IP地址必须是上面填的范围内的IP地址）　　　　9.在租约期限页面填入分配给客户端主机ip的使用期限。一般设置要短些可以具体参考其他规范。这里给他设定期限为1天。并点击下一步。　　　　10.在配置DHCP选项页面中选择“是，现在配置这些选项”点击下一步　　　　11.在路由器页面填入默认网关，局域网内的默认网关是192.168.2.1所以这里填入192.168.2.1点击添加就加入了.点击下一步。　　　　12.在域名称和dns服务器页面什么都不填直接下一步。　　　　13.　在win服务器页面什么也不填，现在现在是配置DHCP所以我们不管这些。直接下一步。　　　　14.在激活作用域页面选择“是，想现在激活此作用域”点击下一步。　　　　在正在完成新建作用域向导页面中点击完成。　　出现此服务器现在是DHCP服务器，在页面也点击完成，到这里此主机已是DHCP服务器了。　　15.到这里配置完了，但是还需要域控制器授权给该服务器，所以还得去授权，　　　　16.打开管理您的服务器页面，点击DHCP服务器选择右边的管理此服务器。　　　　17.在DHCP控制台内点击操作选择授权并点击到此此服务器就是真正的dhcp服务器了。　　　　18.下面就来测试一下DHCP服务器的工作状态，是否能够正常分配动态IP地址给客户机。现在在局域网内打开另一台电脑，在另台电脑里点击本地连接，选择属性，　　　　19.在本地连接属性里选择internet协议，点击属性。　　在internet属性里选择自动获取IP地址。点击确定。并在本地连接属性里点击确定，　　20.在本地连接状态里点击支持，看看IP地址已被分配成了刚刚指定的IP地址范围，范围是192.168.2.10-192.168.2.20在这里被分配了192.168.2.10了。说明DHCP能正常工作了。　　这样DHCP服务器就配置完成了。

下图简单看一下hadoop的发展史 思想: 通过引用数据校验块,使其和原始数据校验块编码产生关联关系,然后听过关联关系恢复,这个技术依赖于线性代数一些姿势. 用处: 用于数据的恢复,可以提高磁盘的利用率 缺点: 时间换空间产物,因为编码解码会浪费时间 纠删码技术原理解释: 假设 x1=1; x2=2; x3=3 x1+2 x2+4 x3=17 x1+2 x2+3 x3=14 根据上面一组方程求x1,x2,x3的值,其实虽然有5个方程,其实最少只需要有三个方程就能求出来另外两个方程 把上面这个原理对应到数据里面就是 x1,x2,x3就相当于是原始数据, x1+2 x2+4 x3=17 x1+2 x2+3 x3=14 这两个方程结果为校验值, 就是假如只有x1这个数据块,但是有下面连个方程,是不是就可以求出对应的x2,和x3了, 如果一个数据是被是3个原始的数据块: 备份机制中:采用2复本机制,至少需要6个数据块才能够保证数据的可靠性,即每个各备份一个即可, 如果是数据块的这种,最少需要4个,他可以容许你的一个数据块的丢失,比如把1丢了,剩下的2和3剩下,通过一个方程就能求出来1的内容,就可以允许一个数据块丢失 之前数据丢失了,直接从别的服务器位置拷贝一个过来就行,hadoop3用纠删码就需要号计算,还需要拿到另外块的数据和计算公式,因为他是要计算的,比如1,2,3三块数据块,比如采用纠删码存储技术,就可以把1号数据丢失,但是某天需要用到1号,数据,就需要从新计算恢复,所以这个就需要耗费时间. 但是我觉得吧,比如hadoop以后可以在这个基础上优化一下 比如说三台服务器,一个文件被切割成了1,2,3三份,具体存储如下 上面三个为纠删码存储方式 下面三个为正常存储方式 hadoop正在往这个方向优化 即先从其他服务器找这个数据块,找不到再用纠删码计算 所以纠删码用于存储冷数据,冷数据指的是平时很少用到的数据 这个用法创建一个eraszing zone(空间),然后放在这个空间的数据,创建目录,把需要纠删码技术存储的把这个文件放到这个路径即可 比如之前的数据时热门的,但是之前并不是存储在这个eraszing zone里面,但是现在就是冷数据,食之无味,弃之可惜,鸡肋也,所以就可以在这个数据拷贝到这个eraszing zone里面,然后把那旧数据原位置删除就行,hadoop也在做一种简单的办法,通过一个命令,修改这个冷数据的存储方式,hadoop正在做, 所以3.0的冷数据还是建议使用这种备份机制,冷门数据是用纠删码(时间换空间) namenode的HA升级了,支持两个以上的namemode, 例如，通过配置三个NameNode和五个JournalNode，群集能够容忍两个节点的故障，而不是一个故障。 但是Active的NameNode始终只有1个，余下的都是Standby。 Standby NN会不断与JN同步，保证自己获取最新的editlog，并将edits同步到自己维护的image中去，这样便可以实现热备，在发生failover的时候，立马切换成active状态，对外提供服务。同时，JN只允许一个active状态的NN写入 以前是支持亚马逊的,现在3.0支持了更多的,尤其是阿里云,说明阿里云正在走向壮大 增加DataNode的 内部 负载均衡,之前是DataNode之间的负载均衡,现在是DataNode内部的负载均衡,比如DataNode这台机器有三块磁盘,然后发现只有一块磁盘写满了,另外两块磁盘都没怎么用,这时候输入一个命令,他就可以帮你重新分配一下 现在可以通过hdfs diskbalancer命令，进行节点内部硬盘间的数据平衡。该功能默认是关闭的，需要手动设置参数dfs.disk.balancer.enabled为true来开启。 yarn timeline service做了升级,yarn timeline service是yarn是资源管理和任务调度,这timeline service就是监控这个任务的,什么时候启动的,用到了哪些资源,可以用时间序列这个结构来存储这个结构,hadoop的2.5之前,通过jobhistory server来提供任务监控信息的收集,但是他有缺点,底层扩展性和可靠性不高,因为做这个数据量也挺大的,所以在3.0作了相应的修改. 支持opportunistic(机会主义的) containers(容器)和distributed(分布式) scheduling(调度) 在hadoop上面的跑的任务,对资源都是争抢的状态,但是有时候需要协调人物的优先级,在hadoop3.0跑的时候,比如MapReduce任务,hive任务过来,对底层资源都是争抢状态,所以就需要协调人物的优先级,hadoop3.0的yarn就是比较灵活,比如任务在跑的时候,指定了优先级也好,指定了比如2核,8G的固定资源也好,有时候某个时间点根本用不到这么多资源,那个时间段可能只用了一半,释放了一半,这个opportunistic(机会主义的) containers(容器)就可以让不这么重要的任务临时用一下这个临时的资源 yarn配置资源可以配置的更加细化,比如原先是只支持线级别,现在支持点级别 比如这个hive依赖hadoopclient,但是还依赖某一个jar包的1.0版本,但是呢,这个hadoopclient依赖这个jar包的2.0版本,然后这两个jar包放到一起,肯定报错,因为名字一样,版本不一样,使用就会紊乱 优化,将这个hadoop client的jar包放到另外一个空间,隔离起来,这样就不会乱了 以上内容纯手敲,如有疑问或者错误请留言或者私信 以上内容纯手敲,如有疑问或者错误请留言或者私信 以上内容纯手敲,如有疑问或者错误请留言或者私信

由于namenode在内存中维护系统中的文件和数据块的映射信息，所以对于一个海量文件的集群来说，内存将成为系统横向扩展瓶颈。Hadoop在2.x的版本引入了联邦HDFS（HDFS Federation），通过在集群中添加namenode实现。 Federation的架构： 1、每个namenode相互独立，单独维护一个由namespace元数据和数据块池（block pool）组成的命名空间卷（namespace volume）——图中的NS-x。 2、数据块池包含该命名空间下文件的所有数据块。命名空间卷相互独立，两两间互不通信，即使一个namenode挂掉，也不会影响其他namenode 3、datanode被用作通用的数据存储设备，每个datanode要向集群中所有的namenode注册，且周期性的向所有namenode发送心跳和报告，并执行来自所有namenode的命令 4、当一个namespace被删除后，所有datanode上与其对应的block pool也会被删除。当集群升级时，每个namespacevolume作为一个基本单元进行升级。 虽然引入了多个namenode管理多份namespace，但是对于单个namenode，依然存在单点故障问题（Single point of failure），如果某个namenode挂掉了，那么所有客户端都无法操作文件。 联邦hdfs仍然需要引入secondary namenode。直到secondary namenode满足以下所有条件时，才能提供服务： 1、将命名空间镜像导入内存 2、重演编辑日志 3、接收到足够的来自datanode的块映射报告并退出安全模式。 保障集群的可用性，可以使用NAS共享存储。主备namenode之间通过NAS进行元数据同步。但是有一下缺陷： 1、硬件设备必须支持NAS 2、部署复杂，部署完namenode还需要在NFS挂载、解决NFS的单点及脑裂，容易出错 3、无法实现同一时间只能有一个namenode写数据 Hadoop2针对以上问题增加了QJM（Quorum Journal Manager），由多个JN组成，一般配置为奇数个。QJM中有一对active-standby的namenode。当active namenode失效时，standby namenode会接管它继续提供服务。 工作原理如下： 1、namenode之间通过一组 journal node 共享编辑日志，standby namenode接管后，需要读取整个编辑日志来与active namenode同步状态，并继续读取active namenode写入的新操作。 2、datanode需要同时向这组active-standby namenode发送数据块处理报告，因为数据块的映射信息保存在namenode的内存中。 3、客户端使用ZKFC（zookeeper failover-controller）来处理namenode失效问题，该进程运行在每个namenode上，通过heartbeat监测active namenode是否失效 4、secondary namenode的角色被standby namenode取代，由standby namenode为active namenode设置check point 5、QJM的实现没有使用zookeeper。但是在HA选举active namenode时，使用了zookeeper。 6、在某些特殊情况下（如网速慢），可能发生故障转移，这时有肯能两个namenode都是active namenode——脑裂。QJM通过fencing（规避）来避免这种现象。 Namenode(包括 YARN ResourceManager) 的主备选举是通过 ActiveStandbyElector 来完成的，ActiveStandbyElector 主要是利用了 Zookeeper 的写一致性、 临时节点和观察者机制 1、 创建锁节点： 如果 ZKFC 检测到对应的 NameNode 的状态正常，那么表示这个 NameNode有资格参加Zookeeper 的主备选举。如果目前还没有进行过主备选举的话，那么相应的会发起一次主备选举，尝试在 Zookeeper 上创建一个路径为/hadoopha/${dfs.nameservices}/ActiveStandbyElectorLock 的临时结点， Zookeeper 的写一致性会保证最终只会有一次结点创建成功，那么创建成功的 NameNode 就会成为主 NameNode， 进而切换为 Active 状态。而创建失败的 NameNode 则切换为 Standby 状态。 2、 注册 Watcher 监听： 不管创建/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点是否成功， ZKFC 随后都会向 Zookeeper 注册一个 Watcher 来监听这个节点的状态变化事件， ActiveStandbyElector 主要关注这个节点的 NodeDeleted 事件。 3、 自动触发主备选举： 如果 Active NameNode 状态异常时， ZKFailoverController 会主动删除临时结点/hadoop-ha/ {dfs.nameservices}/ActiveStandbyElectorLock 结点的流程，如果创建成功，这个本来处于 Standby 状态的 NameNode 就选举为主 NameNode 并随后开始切换为 Active 状态。 4、 当然，如果是 Active 状态的 NameNode 所在的机器整个宕掉的话，那么根据 Zookeeper 的临时节点特性， /hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换。 脑裂的原因 如果 Zookeeper 客户端机器负载过高或者正在进行 JVM Full GC，那么可能会导致 Zookeeper 客户端到服务端的心跳不能正常发出，一旦这个时间持续较长，超过了配置的 Zookeeper Session Timeout 参数的话， Zookeeper 服务端就会认为客户端的 session 已经过期从而将客户端的 Session 关闭。“假死”有可能引起分布式系统常说的双主或脑裂(brain-split) 现象。具体到本文所述的 NameNode，假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFC 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑， NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，即使随后 NameNode1 对应的 ZKFailoverController 因为负载下降或者 Full GC 结束而恢复了正常，感知到自己和 Zookeeper 的 Session 已经关闭，但是由于网络的延迟以及 CPU 线程调度的不确定性，仍然有可能会在接下来的一段时间窗口内NameNode1 认为自己还是处于 Active 状态。这样 NameNode1 和 NameNode2 都处于Active 状态，都可以对外提供服务。这种情况对于 NameNode 这类对数据一致性要求非常高的系统来说是灾难性的，数据会发生错乱且无法恢复。 Hadoop 的 fencing 机制防止脑裂： 中文翻译为隔离，也就是想办法把旧的 Active NameNode 隔离起来，使它不能正常对外提供服务。 ZKFC 为了实现 fencing，会在成功创建 Zookeeper临时结点 hadoop-ha/ {dfs.nameservices}/ActiveBreadCrumb 的持久节点，这个节点里面也保存了 Active NameNode 的地址信息。 正常关闭 Active NameNode时， ActiveStandbyElectorLock 临时结点会自动删除，同时， ZKFC 会删除 ActiveBreadCrumb结点。但是如果在异常的状态下 Zookeeper Session 关闭 (比如前述的 Zookeeper 假死)，那么由于 ActiveBreadCrumb 是持久节点，会一直保留下来。后面当另一个 NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而会对旧的 ActiveNameNode 进行 fencing Hadoop ****的两种 fencing 机制： 只有在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始 对外提供服务。 基于 QJM 的共享存储系统的总体架构： 基于 QJM 的共享存储系统主要用于保存EditLog，并不保存 FSImage 文件。 FSImage 文件还是在 NameNode 的本地磁盘上。 QJM共享存储的基本思想来自于 Paxos 算法，采用多个称为 JournalNode 的节点组成的JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。 每次NameNode 写 EditLog 的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority) 的 JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。如果有 N 台JournalNode，那么根据大多数的原则，最多可以容忍有 (N-1)/2 台 JournalNode 节点挂掉。uf0d8 基于 QJM 的共享存储系统的数据同步机制： Active NameNode 和 StandbyNameNode 使用JouranlNode 集群来进行数据同步的过程如图所示， Active NameNode 首先把 EditLog 提交到 JournalNode 集群，然后 Standby NameNode 再从 JournalNode 集群定时同步 EditLog

数据库Failover：FailOver中文为故障切换。Dataguard方式的一种切换模式，是不可逆的。当主数据库发生宕机，且不能及时恢复时，Oracle会丢弃主数据库，将备用数据库转变为主数据库。当failover之后，备用数据库变成为主数据库，从而丢失了备用数据库的所有能力，也就是说，不能再返回到备用模式。Failover有以下特点：主数据库offline，备用数据库online，这种操作由系统和软件失败引起。即使在备用数据库上应用重做日志，也可能出现数据丢失的现象，除非备用数据库运行在guaranteedprotection模式下。原主数据库重新使用时必须reinstantiated(startinstance)。其它的备用数据库也需reinstantiated。在主数据库正常工作时，Oracle允许DBA将主数据库切换到备用数据库，此备用数据库变为主数据库，而原主数据库变为备用数据库。数据库的切换可以从主数据库角色切换到备用数据库角色，也可从备用数据库角色切换到主数据库角色。

失败后跳转！这个是在oracle 集群的时候用的属性a b两个节点.a节点down掉后会将原来连接a点的连接会跳转到b点上.

顾名思义，oracle的failover是指在oracle集群汇总，客户端当前连接的实例发生故障时，oracle会自动将连接切换到另外一个实例上的情况。 或者说，当用户连接到RAC环境时，用户实际是连接到RAC中的一个实例，用户的查询等操作也是由该实例完成的，如果该实例down掉了，那么用户连接会被转移到其他健康实例，而这种转换对于用户是透明的，用户的select语句仍然继续返回结果集，感觉不到异常。 可以尝试通过下面实例来体现以下： 1，连接到rac $ sqlplus user/password@instance1; 2, 确认用户当前连接的实例 SQL> slect instance_name from v$instance; instance1; 3, 关闭instance1 SQL>shutdown abort; 4,等待几秒后，在第一次连接的session中继续执行查询； SQL> slect instance_name from v$instance; instance2;

什麼鬼

DHCP服务器具有三种IP的分配方式，手动分配，自动分配和动态分配。其中动态分配功能最为强大，配置也最为烦琐。目前的DHCP服务器一般支持全部的几种分配方式或者是其中的两种。手动分配：在手动分配中，网络管理员在DHCP服务器通过手工方法配置DHCP客户机的IP地址。当DHCP客户机要求网络服务时，DHCP服务器把手工配置的IP地址传递给DHCP客户机。自动分配：在自动分配中，不需要进行任何的IP地址手工分配。当DHCP客户机第一次向DHCP服务器租用到IP地址后，这个地址就永久地分配给了该DHCP客户机，而不会再分配给其他客户机。动态分配：当DHCP客户机向DHCP服务器租用IP地址时，DHCP服务器只是暂时分配给客户机一个IP地址。只要租约到期，这个地址就会还给DHCP服务器，以供其他客户机使用。如果DHCP客户机仍需要一个IP地址来完成工作，则可以再要求另外一个IP地址。动态分配方法是惟一能够自动重复使用IP地址的方法，它对于暂时连接到网上的DHCP客户机来说尤其方便，对于永久性与网络连接的新主机来说也是分配IP地址的好方法。DHCP客户机在不再需要时才放弃IP地址，如DHCP客户机要正常关闭时，它可以把IP地址释放给DHCP服务器，然后DHCP服务器就可以把该IP地址分配给申请IP地址的DHCP客户机。

DHCP的工作流程的四个步骤：第一步： 客户端发送 DHCPdiscovery 包，请求DHCP服务器，就是查找网络上的DHCP服务器；第二步： 服务器向回应客户端的 DHCPoffer 包，目的告诉客户端，我能为你提供IP地址；第三步： DHCPrequest 包，客户端向服务器请求IP地址；第四步： DHCPack 包，确认包，服务器向客户端分配IP地址。DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是一个局域网的网络协议，使用UDP协议工作。主要有两个用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段，在RFC 2131中有详细的描述。DHCP有3个端口，其中UDP67和UDP68为正常的DHCP服务端口，分别作为DHCP Server和DHCP Client的服务端口；546号端口用于DHCPv6 Client，而不用于DHCPv4，是为DHCP failover服务，这是需要特别开启的服务，DHCP failover是用来做“双机热备”的。

1、DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是一个局域网的网络协议，使用UDP协议工作， 主要有两个用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段，在RFC 2131中有详细的描述。DHCP有3个端口，其中UDP67和UDP68为正常的DHCP服务端口，分别作为DHCP Server和DHCP Client的服务端口；546号端口用于DHCPv6 Client，而不用于DHCPv4，是为DHCP failover服务，这是需要特别开启的服务，DHCP failover是用来做“双机热备”的。2、与传统的接入方式相比，PPPoE具有较高的性价比，它在包括小区组网建设等一系列应用中被广泛采用，目前流行的宽带接入方式ADSL 就使用了PPPoE协议。通过ADSL方式上网的计算机大都是通过以太网卡（Ethernet）与互联网相连的。同样使用的还是普通的TCP/IP方式，并没有附加新的协议。另外一方面，调制解调器的拨号上网，使用的是PPP协议，即Point to Point Protocol，点到点协议，该协议具有用户认证及通知IP地址的功能。PPP over Ethernet（PPPoE）协议，是在以太网络中转播PPP帧信息的技术，尤其适用于ADSL等方式。

1、首先你要确定不用ha的时候你的hadoop集群是正常的，不然找错误的方向就偏离了2、如果都正常，配置ha 需要zookeeper，先要看看是不是zookeeper没有配置好的问题3、如果都正常，在hadoop安装目录执行sbin/hadoop-daemon.sh start zkfc，这句是启动zookeeper选举制度，然后执行bin/hdfs haadmin -transitionToActive nn2 其中nn2是你的namenode中的一个4、你在hadoop-env.sh中是需要配置JAVA_HOME的，但是不需要配置其他，HADOOP_HOME和PATH是需要配置在/etc/profile中的

分类: 电脑/网络 >> 硬件 解析: SATA 接口比同转速的IDE接口的传输速度要快,价格比较同容量同转速同品牌的硬盘便宜80-150块钱左右，而且内置高速缓存通常都在8M以上，而普通IDE缓存都在2M左右，相差甚远； 更大的区别在于： 一、（SATA不依赖于系统总线的带宽，而是内置时钟。第一代SATA内置1500MHz时钟，可以达到150M字节/秒的接口带宽。由于不再依赖系统总线频率，每一代SATA升级带宽的增加都是成倍的：第二代300M字节/秒(即SATA-II),并且支持热插拔; 二、SATA不再使用过时的并行总线接口，转用串行总线，整个风格完全改变。 SATA与原来的IDE相比有很多优越性，最明显的就是数据线从80 pin变成了7 pin，而且IDE线的长度不能超过0.4米，而SATA线可以长达1米，安装更方便，利于机箱散热。除此之外，它还有很多优点： (1)、一对一连接，没有主从盘的烦恼；而IDE一个接口只能接两个IDE设备，而且还要分主从设备，如果一个接口接上两个IDE设备后就会共同分享这一带宽，从而速度大幅度下降； （2）、每个设备都直接与主板相连，独享150M字节/秒带宽，设备间的速度不会互相影响。 （3）、SATA提高了错误检查的能力，除了对CRC对数据检错之外，还会对命令和状态包进行检错，因此和并行ATA相比提高了接入的整体精确度，使串行ATA在企业RAID和外部存储应用中具有更大的吸引力。 （4）、SATA的信号电压最高只有0.5伏，低电压一方面能更好地适应新平台强调3.3伏的电源趋势，另一方面有利于速度的提高。 （5）、SATA II可以通过Port Multiplier，让每一个SATA接口可以连接4-8个硬盘，即主板有4个SATA接口，可以连接最多32个硬盘。 （6）、还有一个非常有趣的技术，叫Dual host active fail over。它可以通过Port Selector接口选择器，让两台主机同时接一个硬盘。这样，当一台主机出现故障的时候，另一台备用机可以接管尚为完好的硬盘阵列和数据； （7）、SATA-II在SATA的基础上加入NCQ原生指令排序、存储设备管理（Enclosure Management）、底板互连、数据分散/集中这四项新特性。提高读盘效率，减少磁头的内外圈来回摆动次数； （8）、SATA-I代需要在安装操作系统前用SATA接口驱动程序软盘引导计算机，然后安装，且CMOS设置较为复杂，而SATA-II的出现，在许多主板生产厂商的支持下，已经不需要驱动软盘的引导可直接由主板识别，且CMOS设置也更为简单，自动化程序提高。

选正常启动WINDOWS7，它会自动恢复系统，你耐心等待一下几行了。

不可以等同1. 功能不同Server Core支持以下服务器的角色： Active Directory Domain Services (AD DS) Active Directory Lightweight Directory Services (AD LDS) DHCP Server DNS Server File Services Print Services Streaming Media Services同时，还支持以下可选的特性：Microsoft Failover Cluster Network Load Balancing Subsystem for UNIX-based Applications Windows Backup Multipath I/O Removable Storage Management Windows Bitlocker Drive Encryption Simple Network Management Protocol (SNMP) Windows Internet Naming Service (WINS) Telnet client Quality of Service (QoS)与之前集成在Windows Server 2008里的Hyper-V模块/插件不同，Hyper-V Server 2008是一个独立的服务器操作系统，有Windows系统内核但没有GUI图形界面。它能直接运行在裸机上,这款产品不内置管理console，也不支持HA群集，功能有限2. 价钱不同，前者要钱的，hyper-V 2008是免费的

最近与同行 科技 交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。 本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。 首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。 基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是"伪"分布式数据库？从架构先进性来看，这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。 NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图： 这些大多也是NewSQL数据库产品主要宣传的点，不过这些看起来很美好的功能是否真的如此？接下来针对以上几点分别阐述下的我的理解。 这是把双刃剑。 CAP限制 想想更早些出现的NoSQL数据库为何不支持分布式事务（最新版的mongoDB等也开始支持了），是缺乏理论与实践支撑吗？并不是，原因是CAP定理依然是分布式数据库头上的颈箍咒，在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务？ 那么NewSQL数据库突破CAP定理限制了吗？并没有。NewSQL数据库的鼻主Google Spanner（目前绝大部分分布式数据库都是按照Spanner架构设计的）提供了一致性和大于5个9的可用性，宣称是一个“实际上是CA”的，其真正的含义是 系统处于 CA 状态的概率非常高，由于网络分区导致的服务停用的概率非常小 ，究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，另外就是其高效的运维队伍,这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime 和CAP理论》。 完备性 ： 两阶段提交协议是否严格支持ACID，各种异常场景是不是都可以覆盖？ 2PC在commit阶段发送异常，其实跟最大努力一阶段提交类似也会有部分可见问题，严格讲一段时间内并不能保证A原子性和C一致性（待故障恢复后recovery机制可以保证最终的A和C）。完备的分布式事务支持并不是一件简单的事情，需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常，通过严格的测试。之前跟某友商交流，他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的，他们都有案例跑不过，圈内人士这么笃定，也说明了 分布式事务的支持完整程度其实是层次不齐的。 但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制，跨资源的DML、DDL等都依赖其实现，如果这块的性能、完备性打折扣，上层跨分片SQL执行的正确性会受到很大影响。 性能 传统关系数据库也支持分布式事务XA，但为何很少有高并发场景下用呢？ 因为XA的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。 NewSQL数据库的分布式事务实现也仍然多基于两阶段提交协议，例如google percolator分布式事务模型， 采用原子钟+MVCC+ Snapshot Isolation（SI），这种方式通过TSO(Timestamp Oracle)保证了全局一致性，通过MVCC避免了锁，另外通过primary lock和secondary lock将提交的一部分转为异步，相比XA确实提高了分布式事务的性能。 但不管如何优化，相比于1PC，2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失，尤其是跨节点的数量比较多时会更加显著，例如在银行场景做个批量扣款，一个文件可能上W个账户，这样的场景无论怎么做还是吞吐都不会很高。 虽然NewSQL分布式数据库产品都宣传完备支持分布式事务，但这并不是说应用可以完全不用关心数据拆分，这些数据库的最佳实践中仍然会写到，应用的大部分场景尽可能避免分布式事务。 既然强一致事务付出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务？尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中。尝试将一致性要求弱化，便是柔性事务，放弃ACID(Atomicity,Consistency, Isolation, Durability)，转投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发OLTP场景，我个人更建议使用柔性事务而非强一致的分布式事务。关于柔性事务，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与框架（例如阿里刚开源的Fescar），限于篇幅不再赘述，有空再单独写篇文章。 HA与异地多活 主从模式并不是最优的方式，就算是半同步复制，在极端情况下（半同步转异步）也存在丢数问题，目前业界公认更好的方案是基于paxos分布式一致性协议或者其它类paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了这种方式，基于Paxos协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了failover时间，提高了可用性，特别是减少了运维的工作量，这种方案技术上已经很成熟，也是NewSQL数据库底层的标配。 当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将MySQL存储改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，预计不远的未来主从模式可能就成为 历史 了。 需要注意的是很多NewSQL数据库厂商宣传基于paxos或raft协议可以实现【异地多活】，这个实际上是有前提的，那就是异地之间网络延迟不能太高 。以银行“两地三中心”为例，异地之间多相隔数千里，延时达到数十毫秒，如果要多活，那便需异地副本也参与数据库日志过半确认，这样高的延时几乎没有OLTP系统可以接受的。 数据库层面做异地多活是个美好的愿景，但距离导致的延时目前并没有好的方案。 之前跟蚂蚁团队交流，蚂蚁异地多活的方案是在应用层通过MQ同步双写交易信息，异地DC将交易信息保存在分布式缓存中，一旦发生异地切换，数据库同步中间件会告之数据延迟时间，应用从缓存中读取交易信息，将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理，等数据同步追上之后再将这些业务对象从黑名单中剔除。由于双写的不是所有数据库操作日志而只是交易信息，数据延迟只影响一段时间内数据，这是目前我觉得比较靠谱的异地度多活方案。 另外有些系统进行了单元化改造，这在paxos选主时也要结合考虑进去，这也是目前很多NewSQL数据库欠缺的功能。 Scale横向扩展与分片机制 paxos算法解决了高可用、高可靠问题，并没有解决Scale横向扩展的问题，所以分片是必须支持的。NewSQL数据库都是天生内置分片机制的，而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点，然后进行分片的分裂、数据迁移、合并，这些过程应用是无感知的，这省去了DBA的很多运维工作量。以TiDB为例，它将数据切成region，如果region到64M时，数据自动进行迁移。 分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式（range、取模、一致性哈希或者自定义路由表）、路由规则、拆分库表数量、扩容方式等。相比NewSQL数据库，这种模式给应用带来了很大侵入和复杂度，这对大多数系统来说也是一大挑战。 这里有个问题是NewSQL数据库统一的内置分片策略（例如tidb基于range）可能并不是最高效的，因为与领域模型中的划分要素并不一致，这导致的后果是很多交易会产生分布式事务。 举个例子，银行核心业务系统是以客户为维度，也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的，但如果按照各表主键range进行分片，这个交易并不能在一个分片上完成，这在高频OLTP系统中会带来性能问题。 分布式SQL支持 常见的单分片SQL，这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库，所以支持的SQL会更完整，包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计，不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。 NewSQL数据库一般并不支持存储过程、视图、外键等功能，而中间件模式底层就是传统关系数据库，这些功能如果只是涉及单库是比较容易支持的。 NewSQL数据库往往选择兼容MySQL或者PostgreSQL协议，所以SQL支持仅局限于这两种，中间件例如驱动模式往往只需做简单的SQL解析、计算路由、SQL重写，所以可以支持更多种类的数据库SQL。 SQL支持的差异主要在于分布式SQL执行计划生成器，由于NewSQL数据库具有底层数据的分布、统计信息，因此可以做CBO，生成的执行计划效率更高，而中间件模式下没有这些信息，往往只能基于规则RBO（Rule-Based-Opimization），这也是为什么中间件模式一般并不支持跨库join，因为实现了效率也往往并不高，还不如交给应用去做。 存储引擎 传统关系数据库的存储引擎设计都是面向磁盘的，大多都基于B+树。B+树通过降低树的高度减少随机读、进而减少磁盘寻道次数，提高读的性能，但大量的随机写会导致树的分裂，从而带来随机写，导致写性能下降。NewSQL的底层存储引擎则多采用LSM，相比B+树LSM将对磁盘的随机写变成顺序写，大大提高了写的性能。不过LSM的的读由于需要合并数据性能比B+树差，一般来说LSM更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比，在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能，所以读性能基本不会下降太多。NewSQL数据由于多副本、分布式事务等开销，相比单机关系数据库SQL的响应时间并不占优，但由于集群的弹性扩展，整体QPS提升还是很明显的，这也是NewSQL数据库厂商说分布式数据库更看重的是吞吐，而不是单笔SQL响应时间的原因。 成熟度与生态 分布式数据库是个新型通用底层软件，准确的衡量与评价需要一个多维度的测试模型，需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线DDL等等，虽然NewSQL数据库发展经过了一定时间检验，但多集中在互联网以及传统企业非核心交易系统中，目前还处于快速迭代、规模使用不断优化完善的阶段。 相比而言，传统关系数据库则经过了多年的发展，通过完整的评测，在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势，同时对已建系统的兼容性也更好。 对于互联网公司，数据量的增长压力以及追求新技术的基因会更倾向于尝试NewSQL数据库，不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。 对于传统企业例如银行这种风险意识较高的行业来说，NewSQL数据库则可能在未来一段时间内仍处于 探索 、审慎试点的阶段。基于中间件+分库分表模式架构简单，技术门槛更低，虽然没有NewSQL数据库功能全面，但大部分场景最核心的诉求也就是拆分后SQL的正确路由，而此功能中间件模式应对还是绰绰有余的，可以说在大多数OLTP场景是够用的。 限于篇幅，其它特性例如在线DDL、数据迁移、运维工具等特性就不在本文展开对比。 总结 如果看完以上内容，您还不知道选哪种模式，那么结合以下几个问题，先思考下NewSQL数据库解决的点对于自身是不是真正的痛点： 如果以上有2到3个是肯定的，那么你可以考虑用NewSQL数据库了，虽然前期可能需要一定的学习成本，但它是数据库的发展方向，未来收益也会更高，尤其是互联网行业，随着数据量的突飞猛进，分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。 如果你还未做出抉择，不妨再想想下面几个问题： 如果这些问题有多数是肯定的，那还是分库分表吧。在软件领域很少有完美的解决方案，NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案，它最大程度复用传统关系数据库生态，通过中间件也可以满足分库分表后的绝大多数功能，定制化能力更强。 在当前NewSQL数据库还未完全成熟的阶段，分库分表可以说是一个上限低但下限高的方案，尤其传统行业的核心系统，如果你仍然打算把数据库当做一个黑盒产品来用，踏踏实实用好分库分表会被认为是个稳妥的选择。 很多时候软件选型取决于领域特征以及架构师风格，限于笔者知识与所属行业特点所限，以上仅为个人粗浅的一些观点，欢迎讨论。

TCP/IP 连接失败。 看看你的数据库的服务有没有开启.

配置文件写错了

kobe bryant&shaquille o"nealthere are so many emotions at the end of the season nobody likes to talk about it but one of them is fear fear that you come this far when it can all end the dream could die but me? i like the fear it means I"m close it means I"m readychris paul&dwight howardWe"re gonna win, yeah that"s not me brag, that"s me believing that"s me believe in myself and my teammates and trust me if you ask anyone who"s ever won a ring anyone who"s ever been a champion they believe it too we are not here to loselebron james&kevin garnetti dream about winning it all since i was probably 9 years old i remember seeing jordan/bird winning it all i made up my mind right then, that was gonna be me that i was gonna be part of that some dreams fail over time but not this onesteve nash&jason kiddAfter 82 games There"s Part of you To wonder if you have anything left If you have anything more to give But somehow from somewhere you find it You dig deeper， you have to Because if you don"t you go home

外围网络中有一个 Web 服务器，后端生产网络中有一个独立的 SQL Server （或 SQL Server 群集实例），防火墙将两个网络隔开。MSDTC 需要在 Web 服务器和后端 SQL Server 之间使用特定端口对其进行配置，以限制端口在两个网络之间的防火墙中打开。举例来说，我们配置 MSDTC 令其使用端口 5000。在前端 Web 服务器中需要做两件事来限制 MSDTC 将要使用端口。配置 DCOM 可以使用的端口配置可供 MSDTC 使用的特定端口步骤1. 在 Web 服务器的 Run 菜单中启动 Dcomcnfg.exe。2. 扩展 Component Services，右键单击 My Computer，选择 Properties。3. 选择 Default Protocols 选项卡。4. 单击 Properties 按钮。5. 单击 Add。6. 输入 MSDTC 将要使用端口的端口范围。在本例中，我将使用端口 5001-6000。7.单击 OK，返回 My Computer Properties 窗口，然后单击 OK。这一步很关键，为临时端口修改注册表。8. 启动 Regedt32.exe。9. 找到 HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSDTC。10. 右键单击 MSDTC 项，选择 New and DWord (32-bit) Value。11. 输入 ServerTcpPort 作为名称。12. 右键单击 ServerTcpPort 项，然后选择 Modify。13. 将 Radio Button 改为 Decimal，然后在 Value Data 处输入 5000，单击 OK。下图为修改后的注册表项：14. 重新启动 MSDTC Service （单机情况下）或在群集情况下在 Failover Cluster Manager 中运行 MSDTC Resource offline/online。确认 MSDTC 使用了正确的端口：打开管理命令提示符，运行 Netstat –ano 来获取端口和进程标识符（PID）启动 Task Manager 并选择 Details 选项卡找到 MSDTC.exe 并获取 PID浏览输出并显示其是 MSDTC现在 DTC 将会使用注册表中的特定端口，其他进程不会尝试使用与其相同的端口，从而防止了端口重叠。

配置没问题，没见到你将访问控制生效的语句，可能是没有贴。默认是不通的。如果重启没用的话，换硬件吧

右击principal database->Tasks->launch database mirroring monitor,然后将需要监控的DB添加进来,如果同步会出现同步的字眼.Mirror在没有见证服务器的情况下有2中模式:High perforcemance和High safety without automatic failover,可以仔细研究下.主机与备机可以用命令: alter database backuptest set partner failover; 进行切换.具体的也可以参考:http://msdn.microsoft.com/zh-cn/library/ms190030.aspx

fail的用法及搭配：1. fail是一个动词，表示失败；没有完成；没有完成；没有完成；没有完成；没有通过；没有通过。例句: I failed in my attempt to persuade her.我没能劝住她。He failed to keep the appointment.他没有履行诺言。The examiners failed over half the candidates.经主考老师评估，超过一半的考生不合格。3.（不及格），这个 fail可以用作和非宾语（和物动词一样），因此下面的 fail后面的介词 in可以被省略：他没有通过驾照。He failed his driving test.有时指“不及格”（及事物）。比如：教师让半数同学不及格。The examiners failed over half the candidates.注意：在现代英语中，有时还会加上一个“on”。比如：我的笔试通过了，但是我的口试没有通过。I passed the written exam, but I failed the oral exam.3.表示“不能”、“没有”、“忘记”的不定式。比如：他没有通过考试。He failed in the exam.指“无法完成某件事情”，有时可以后缀“完成”。对比：他无法使她信服。正：He failed to persuade her.正：He failed in persuading her.

"SCSI-3（SCC-2）定义了一种机制：应用程序使用一个逻辑单元号（Logical unit number）与SCSI存储设备进行通信，从而确定附加到（attach）其上的逻辑单元（Logical Unit）信息，并能对其进行配置。LUNZ就是逻辑单元号为0的设备，对于VNX或CLARiiON来讲，当主机端没有物理逻辑单元0时，LUNZ便会作为一个虚假的逻辑单元0呈现给主机，从而为主机软件提供一条路径来发送命令给SCSI设备（存储阵列）。例如，运行在主机上的Navisphere/Unisphere Agent使用LUNZ或其他存储设备与存储系统进行通信，注册initiator的信息（IP，主机名，failover mode等）。如果CLARiiON没有绑定（bind）任何LUN，那么LUNZ就使得主机操作系统以及Powerpath可以看见并操作CLARiiON；如果绑定一个LUN给主机且设置HLU=0，那么LUNZ便会被其所替代。以后，Agent就将与该设备（LUN）通信，而不是LUNZ。可见，LUNZ的目的是为主机与存储系统提供一条路径，使得它们能够在设备层面进行通信。其实这也仅仅是在系统初始配置时才有意义，因为此时还没有配置任何的LUN给到主机。一旦主机得到真正的LUN0之后，LUNZ设备便会消失。EMC中文技术支持论坛的文档https://community.emc.com/docs/DOC-16365里面蛮详细的。

一、软件需求　　操作系统：Windows XP 　　JDK：jdk1.6.0_16，下载地址：http://www.oracle.com/technetwork/java/javase/downloads/index.html 。　　Apache ：httpd-2.2.17 （一个），下载地址：http://httpd.apache.org/ 。 　　Tomcat：tomcat-7.0.2 （两个），下载地址：http://tomcat.apache.org/download-70.cgi 。 　　mod_jk：mod_jk-apache-2.0.55.so （1个），下载地址：http://tomcat.apache.org/download-70.cgi 。二、环境搭建　　安照上篇《windows下apache tomcat整合》中的方法安装jdk/apache/tomcat三、环境配置（两种配置）　　1. 原始配置　　　　(1)apache配置　　　　　　 1>mod_jk.conf(apache/conf)mod_jk.conf 2>httpd.conf(apache/conf)httpd.conf 3>workers.properties(apache/conf)workers.properties　 (2)tomcat配置　　　　　　1>server.xml(tomcat/conf)server.xml 2>web.xml(tomcat/conf)web.xml(tomcat下的)　　　　 3>catalina.bat(tomcat/bin)这个文件只是添加了一个对tomcat内存优化配置的更改（前两行）catalina.bat 以上最后的两个文件及前面有些配置使用该优化tomcat和jdk的，配置完成后的各个配置文件，具体操作步骤如下：　　(1)负载均衡　　　　　找到Apache安装目录下conf目录中的httpd.conf文件。　　　　在文件最后添加一句：include "D:webserverApache GroupApache2confmod_jk.conf"(具体路径是你放置的位置而定)　　　　接着在conf目录中新建文件mod_jk.conf并添加下面的内容：　　　　　　#加载mod_jk Module　　　　　　LoadModule jk_module modules/mod_jk-apache-2.0.59.so　　　　　　#指定 workers.properties文件路径　　　　　　JkWorkersFile conf/workers.properties　　　　　　#指定哪些请求交给tomcat处理,"controller"为在workers.propertise里指定的负载分配控制器名　　　　　　JkMount /*.jsp controller　　　　　　在conf目录下新建workers.properties文件并添加如下内容：　　　　#server　　　　worker.list = controller　　　　#========tomcat1========　　　　worker.tomcat1.port=11009　　　　worker.tomcat1.host=localhost　　　　worker.tomcat1.type=ajp13　　　　worker.tomcat1.lbfactor = 1　　　　#========tomcat2========　　　　worker.tomcat2.port=12009　　　　worker.tomcat2.host=localhost　　　　worker.tomcat2.type=ajp13　　　　worker.tomcat2.lbfactor = 1　　　　#（解释一下AJP13是 Apache JServ Protocol version 1.3）　　　　#========controller,负载均衡控制器========　　　　worker.controller.type=lb　　　　worker.controller.balanced_workers=tomcat1,tomcat2　　　　worker.controller.sticky_session=1　　　　将mod_jk-apache-2.0.59.so 复制到Apache的modules目录中。　　　　接下来配置2个Tomcat　　　　打开tomcat1conf server.xml　　　　将Server port 改为11005：<Server port="11005" shutdown="SHUTDOWN">　　　　将Define Connector port改为11080：<Connector port="11080" maxHttpHeaderSize="8192"　　　　将AJP13 Connector port改为11009：<Connector port="11009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" /> 　　　　打开tomcat2confserver.xml　　　　将Server port 改为12005：<Server port="12005" shutdown="SHUTDOWN">　　　　将Define Connector port改为12080：<Connector port="12080" maxHttpHeaderSize="8192"　　　　将AJP13 Connector port改为12009：<Connector port="12009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />　　　　好了，现在建立一个测试程序　　　　分别在两个Tomcat的webapps中建立test目录，并新建test.jsp文件，内容如下：　　　　<%　　　　　　System.out.println("test");　　　　%> 　　　　启动apache, tomcat1, tomcat2

kill -HUP $(cat /var/run/keepalived.pid)

是没有安装好，要重新安装的，我是在网上买了软件和教程的，建议下，几十块钱什么都解决了