berkeley db java,

　　Berkeley DB-数据库复制的较低部分(HA)

　　网络分区

　　BDReplication的实现可能会受到网络隔离问题的影响。

　　例如，假设复制组有n个成员。网络隔离将主站点留在一边，超过一半(n/2)的站点在另一边。master端的站点会继续前进，master会继续接受来自数据库的写请求。不幸的是，另一边的孤立网站意味着他们的主人走了，将举行选举。这次选举会成功，因为这里有n/2个以上的站点，然后这个组里会有两个高手。因为两个主机都可能接受写请求，所以数据库可能会有差异，使得数据不一致。

　　如果在一个组中发现了多个主节点，当主节点检测到这个问题时，将返回DB_REP_DUPMASTER。如果应用程序看到这个返回，它应该将自己重新配置为客户机(通过调用ENV- rep_start ),然后启动选举(通过调用DB_ENV- rep_elect)。这次选举的获胜者可能是前两个主人中的一个，也可能是另一个完全不同的站点。无论如何，这个获胜的系统将引导其他系统达成一致。

　　作为另一个例子，考虑一个复制组有一个主环境和两个客户机A和B，其中A可以升级到主状态，而B不能。然后，假设客户机A与其他两个数据库环境隔离，它的数据变得过时。那我们就说这个高手倒下了，不再在线了。随后，网络隔离修复，客户端A和B进行选举。因为客户端B无法赢得选举，所以客户端A会默认赢得选举。为了再次与B同步，可能在B上提交的事务将不会回滚，直到两个站点可以再次一起向前移动。

　　在这两种情况下，一个步骤是新选出的主引导组成员与其自身保持一致，以便它可以开始向它们发送新信息。这可能会导致信息丢失，因为以前提交的事务尚未回滚。

　　网络隔离是架构中的一个问题，应用程序可能希望实现心跳协议，以最小化糟糕的网络隔离的影响。只要一个主能和组里至少一半的站点通信，就不可能有两个主。如果一个主机不能再与足够多的站点取得联系，它应该将自己重新配置为一个客户端并进行选举。

　　这是另一个工具应用程序，可用于在网络隔离的情况下将损失降至最低。通过为DB_ENV- rep_elect指定一个nsites参数，也就是说，该参数大于组中成员的实际数量，应用程序可以防止系统将自己声明为主站点，除非它们可以与组中的大多数站点进行通信。例如，如果组中有20个数据库环境，并且参数30被分配给DB_ENV- rep_elect方法，那么系统需要与至少16个站点通信，然后才能将自己声明为主站点。

　　为DB_ENV- rep_elect指定一个nsites参数也很有用，该参数小于组中world成员的数量。例如，考虑一个只有两个数据库环境的组。如果孤立他们，没有一个人能获得足够的票数成为高手。合理的选择是指定一个系统的nsites参数为2，另一个为1。这样，当被孤立时，一个系统可以赢得投票权，而另一个系统则不能。这允许其中一个系统在网络被隔离时继续接受写请求。

　　这些级别强调了良好的网络基础设施在bdb复制环境中的重要性。当复制数据库环境处于丢包严重的网络环境时，最好的解决方案可能是选择单个主设备，只有当人工干预决定所选主设备无法再联机时，才会进行选举。

　　复制常见问题

　　Berkeley DB是否支持将写查询从客户端转发到主机？

　　不，不是的伯克利DB RPC服务器代码可以被修改来支持这个功能，但是通常这个协议完全留给应用程序。请注意，没有理由不使用应用程序为复制支持而建立的通信通道来将数据库更新消息转发到主服务器，因为伯克利数据库不要求这些通道专门用于复制消息。

　　我是否可以使用复制跨多个站点对我的环境进行分区？

　　不，这是不可能的。所有复制的数据库必须由复制组中的所有环境平等共享。

　　我正在运行复制，但在客户端上看不到我的数据库。

　　此问题可能是由于应用程序对其数据库使用绝对路径名，而路径名在客户端系统上无效。

　　如何区分伯克利数据库消息和应用程序消息？

　　没有办法区分伯克利数据库消息和特定于应用程序的消息，伯克利DB也没有提供任何方法将应用程序消息包装在伯克利数据库消息中。交换自己消息的分布式应用程序应该将伯克利数据库消息封装在自己的包装器中，或者使用单独的网络连接来发送和接收伯克利数据库消息。此规则的一个例外是新站点的连接信息；伯克利数据库为加入复制组的站点提供了一种简单的方法，用于将连接信息发送到组中的其他数据库环境（有关更多信息，请参见连接到新站点)。

　　我应该如何建立我的发送功能？

　　这取决于应用程序的具体情况。一种常见的方法是将娱乐场和控制参数的大小和数据写入连接到每个远程站点的套接字。在快速的局域网上，最简单的方法可能是构造广播消息。每个伯克利数据库消息将被封装在一个特定于应用程序的消息中，消息头信息指定了消息的预期接收者。但是，这可能需要一个全局编号方案，因为除了为复制组的所有成员广播新的日志记录之外，伯克利DB库还必须能够向客户端发送特定的日志记录。

　　我在主服务器上的每一个控制线程都必须建立自己与每一个客户端的连接吗？我在客户机上的每一个控制线程都必须建立自己与每个主线程的连接吗？

　　这并不总是必要的。在伯克利数据库复制模型中，在主环境中修改数据库的任何控制线程都必须准备好向客户端环境发送消息，并且向客户端环境传递消息的任何控制线程都必须准备好向主环境发送消息。有许多方法可以满足这些要求。

　　最简单的情况可能是在主服务器和客户机上运行一个单一的多线程进程。在主服务器上运行的进程需要到每个客户端的单个写连接和来自每个客户端的单个读连接。在每个客户端上运行的进程将需要来自主设备的单个读连接和到主设备的单个写连接。在主服务器和客户端上的这些进程中运行的线程将使用相同的网络连接来来回回地传递消息。

　　一个常见的复杂情况是在主服务器和客户端上运行多个进程。一个直接的解决方案是增加主服务器上的连接数——主服务器上运行的每个进程都有自己的到每个客户机的写连接。但是，对于主进程中的每个可能的客户端，这仅需要一个额外的连接。主环境仍然只需要来自每个客户机的一个读连接（这可以通过分配一个单独的控制线程来完成，该线程除了接收客户机消息并将它们转发到数据库之外什么也不做)。类似地，每个客户机仍然只需要一个控制线程，该线程接收主消息并将它们转发到数据库，并且还接收数据库消息并将它们转发回主服务器。当然，这种模式要求网络基础设施支持多对一的作者到读者。

　　如果网络连接的数量在多进程模型中是一个问题，并且系统上的进程间通信足够便宜，则另一种方法是让单个进程在主进程和每个客户端之间进行通信，并且每当调用进程的派遣函数时，该进程将消息传递给负责将消息转发给适当客户端的通信进程。或者，广播机制将简化整个网络基础设施，因为进程可能不再需要维护它们自己的特定网络连接。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。