标签: high-availability

我设置了一个数据库镜像,然后使用它connectionstring连接到它:

    Data Source={0};Failover Partner={1};Initial Catalog=AdventureWorks;
    Integrated Security=True;

将一些数据添加到数据库后,我关闭了主服务器,因此镜像服务器成为主服务器.我再次打开连接,得到这个错误:

    System.Data.SqlClient.SqlException: A transport-level error has 
occurred when sending the request to the server. (provider: Shared Memory 
Provider, error: 0 - No process is on the other end of the pipe.)

我认为通过连接字符串中指定的故障转移伙伴,ADO.NET将为我完成工作.那我现在该怎么办？

这个问题很紧迫.非常感谢你的帮助.

我写这应该是多余的小代理应用程序,如初级代理将一台服务器上运行,且冗余的一个将在单独的服务器上运行.是否有一个简单的高可用性框架,我可以用它来实现这种冗余？例如,此HA框架将在实例之间发送ping,并在第一个实例出现故障时在另一个实例上引发某种异常或通知.

假设我在开头有两个memcached节点(节点A,B),当我添加一个新节点C时,一部分键被重新映射,并且由于一致的散列只有其中一些.

假设最初在服务器A处使用键" foo " 的值现在正被映射到服务器C.

当我最终删除节点C时,密钥应该再次映射到节点A,但此时节点A只包含过时数据.

那么,刷新数据是解决这个问题的唯一方法吗？

根据"使用MySQL群集扩展Web数据库指南",MySQL Cluster 7.3可以在使用同步更新复制时获得99,999%的可用性.这将是CAP定理的一个对立面,因为它表明完美的可用性(99,999%可以看作是这样,没有？)并且在分布式系统中一致性是不可行的.

如果无法访问负责副本的datanode,群集将如何响应更新？对于同步更新复制,它必须阻止,这将影响可用性.

指南指出:

• 数据节点内的数据同步复制到节点组内的所有节点.如果数据节点发生故障,则始终存在至少一个存储相同信息的其他数据节点.
• 如果数据节点发生故障,MySQL服务器或应用程序节点可以使用节点组中的任何其他数据节点来执行事务.应用程序只是重试事务,其余数据节点将成功满足请求.

但是,如果节点组包含两个节点和一个崩溃(例如此处),那么它如何工作呢？根据我的理解,没有Node可以将更新复制到使用同步更新复制时更新失败的内容？!复制是否只是在没有节点写入副本的时候暂停？

Twilio和其他HTTP驱动的Web服务具有回退URL的概念,如果主URL超时或以其他方式失败,Web服务会向您选择的URL发送GET或POST.对于Twilio,如果回退URL也失败,他们将不会重试请求.我希望将备用URL托管在单独的计算机上,以便在主服务器关闭或无法访问时,错误不会在以太网中丢失.

我想为次要的某种方式:

1. 将请求存储到后备URL
2. 将请求重播到主服务器上略有不同的URL
3. 重试#2直到成功,然后从队列/数据库中删除请求

是否有一些现有软件可以做到这一点？如果需要,我可以自己构建一些东西,我只是认为这将是某人已经做过的事情.我对HTTP和周围的工具(代理,反向代理等)不太熟悉,无法知道要搜索的正确的流行语.

我正在阅读使用Sparx Enterprise Architect生成的系统需求文档.所有要求都映射到特定用例.

"高可用性"的一些非功能性要求映射到名为"提供高可用性"的用例,标记为<<non-functional>>.对于所有这些都是相当新的,并且努力决定用例是否有用是否有意义 - 因此问题.

如果答案是肯定那么好 - 但如果没有,我有兴趣知道人们对这些要求应如何映射到用例(如果有的话)的意见.

我是hdfs的新手.我正在编写可以连接数据并将数据写入远程hadoop集群的Java客户端.

String hdfsUrl = "hdfs://xxx.xxx.xxx.xxx:8020";
FileSystem fs = FileSystem.get(hdfsUrl , conf);

这很好用.我的问题是如何处理启用HA的hadoop集群.启用HA的hadoop群集将具有两个名称节点 - 一个活动的名称节点和备用名称节点.如何在运行时从客户端代码中识别活动的名称节点.

http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.1.1/bk_system-admin-guide/content/ch_hadoop-ha-3-1.html有关于可用于联系的java类的以下详细信息活动名称节点dfs.client.failover.proxy.provider.[$ nameservice ID]:

This property specifies the Java class that HDFS clients use to contact the Active NameNode. DFS     Client uses this Java class to determine which NameNode is the current Active and therefore which NameNode is currently serving client requests.

Use the ConfiguredFailoverProxyProvider implementation if you are not using a custom implementation.

例如:

<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

我如何在我的Java客户端中使用此类,或者是否有任何其他方法来识别活动的名称节点...

注意:这是我之前关于类似主题的问题的进化延续.

我一直在寻找有关部署和更新Erlang/OTP版本(一组应用程序)的"最佳实践",但是我找不到任何直接的解决方案描述,但只能找到一些"相关信息":

http://blog.equanimity.nl/blog/2013/06/04/continuous-integration-for-erlang-with-travis-ci/

https://www.youtube.com/watch?v=G0eBDWigORY

https://www.youtube.com/watch?v=0ZGHzI9F5YE

我所说的"直接解决方案"是对以下问题的回答:

鉴于生产Erlang/OTP集群的Erlang/OTP版本在几个Erlang节点上运行,这些节点充当高可用性(24/7)REST API,如何定期将新代码推送到该生产集群？有没有最好的做法来做那些像git push heroku master Heroku一样简单的做法？如果没有,在生产中连续重新部署和Erlang/OTP软件的最简单方法是什么？

我已经阅读了"Erlang/OTP in Action"一书来了解如何处理Erlang/OTP应用程序和发行版,在我看来,简单的软件升级并不那么容易.使用reltool时必须生成存档,将该存档移动到生产机器(scp？),在那里解压缩,运行Erlang shell并将新模块加载到Erlang VM中.

另外,"Learn You Some Erlang"一书中指出了以下内容:

"...如果你可以避免整个过程(从现在开始称为relup)并通过重新启动VM并启动新应用程序来进行简单的滚动升级,我建议你这样做."

和

"有人说爱立信的部门使用relups会花费尽可能多的时间测试它们,就像测试应用程序本身一样."

此外,这是另一个建议,以避免生产中的Erlang版本的热交换.

如果这是真的,那么我没有看到'Erlang热代码升级'的任何用处,因为我必须在每次升级时重启VM.这让我不知道在生产中定期部署Erlang/OTP新代码的强大且经过测试的方法.

PS关于我的软件要求的一些注释.

• 我正在编写一组没有任何会话的API入口点,因此在软件更新期间无需维护会话.
• 没有必要分发Erlang/OTP版本,我正在使用内部定制产品.

根据(详细)主题,使用Keepalived&HAProxy作为HA网络服务器loadbalancer与纯粹的keepalived解决方案相比,有什么优势吗？

我正在学习Kubernetes，目前正在深入研究高可用性，虽然我了解我可以使用本地（或远程）etcd以及一组高度可用的setd建立一个高可用性的控制平面（API服务器，控制器，调度程序）小兵（通过Kubernetes本身），我仍然不确定服务在这个概念中的位置。

如果它们位于控制平面中：好的，我可以将它们设置为高度可用。

如果它们生活在某个节点上：好的，但是如果该节点出现故障或以其他任何方式不可用怎么办？

据我了解，需要一些服务来将我的Pod暴露给互联网以及进行负载平衡。因此，没有HA服务，我冒着我的应用程序无法访问的风险（即使该应用程序对于系统的任何其他方面都具有很高的可用性）。