服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

我怎样才能在三个或更多地理位置独立的服务器之间集中MySQL数据?

为了解释这个问题的背景: 我们有一个在Linux服务器上运行的本地PHP应用程序(用于运行在线语言学习课程),并在本地主机上使用MySQL来保存用户数据(例如,testing结果,提交工作的标记,花在不同页面上的时间课程等)。 由于我们有来自不同地理位置的学生,因此我们目前在这些地点(西class牙,英国和香港)附近托pipe了3台虚拟服务器,并将用户添加到离他们最近的服务器上(他们通过不同的URL访问,例如europe.domain.com ,uk.domain.com和asia.domain.com)。 这个工作,但是是一个pipe理的噩梦,因为我们必须记住一个特定的用户在哪个服务器上,用户只能连接到一个服务器。 我们希望以某种方式集中化信息,以便所有用户都可以在任何服务器上看到,并且用户可以连接到3台服务器中的任何一台。 问题是,我们应该用什么方法来实现这一点。 这肯定是一个很多人遇到的问题,但是我还没有find任何结论性的search结果。 我看到的最接近的解决scheme是: 像master-master复制,但我已经阅读了这么多的post,这表明这不是一个好主意,因为像auto_increment字段可以打破。 循环复制,这听起来很完美,但引用O'Reilly的高性能MySQL,“一般来说,环是脆弱和最好的避免” 我们不反对在应用程序中重写代码,以使其能够与任何需要的解决scheme一起工作,但我不确定是否使用复制是正确的。 谢谢, 安迪 PS我应该补充一点,我们尝试写入中央数据库,然后使用本地数据库读取,但不同服务器之间写入的响应时间相当糟糕,写入数据立即可用于读取也很重要,所以如果复制太慢,这可能会导致过期的数据被返回。 编辑:我一直在考虑编写我自己的基本复制脚本,这个脚本涉及到每个用户都有一个服务器ID来说明他的“主服务器”,比如亚洲的用户会被标记为香港服务器自己的服务器 然后复制脚本(这将是一个PHP脚本设置为合理频繁地运行,例如每15分钟左右),将独立运行在系统中的每个服务器上。 他们将通过数据库并将有关用户的任何信息与“主服务器”一起分配给运行脚本的服务器,以便将其发送到系统中的所有其他数据库。 他们还需要吸收已经添加到系统上的其他数据库的新信息,其中“主服务器”标志是运行脚本的服务器。 我需要弄清楚细节并构build处理冲突的逻辑,但是我认为这是可能的,但是我想确保没有一个正确的解决scheme已经在那里,因为它似乎是必须的这是很多人已经遇到的问题。

在数据库迁移后解决SQL连接问题

我们刚刚完成了从SQL 2000到SQL 2008 R2的迁移,并且已经开始间歇性地接收到SqlExceptions以下两条错误消息: 从服务器接收结果时发生传输级错误。 (提供程序:TCP提供程序,错误:0 – 信号量超时期限已过。) 从服务器接收结果时发生传输级错误。 (提供程序:TCP提供程序,错误:0 – 信号量超时期限已过。) 我们有3台Web服务器连接到运行大约100个应用程序的SQL Server(全部访问SQL Server上的相同8个数据库)。 因为2000服务器上没有发生这些exception情况,所以我们认为这不太可能是一个应用程序问题(但是我们并不排除)。 网站上的stream量是典型的,排除了高stream量问题。 旧的SQL 2000盒子有4个CPU和8 GB的RAM,而新的有24 GB的RAM和16个CPU(目前和这个问题未充分利用)。 这些错误几个小时前发生了大约5分钟的时间,并且还没有重新发生。 sys.dm_os_ring_buffers系统视图不显示这些断开连接的条目,并且在服务器或客户机上都没有对应的事件日志条目。 一些谷歌search发现了一些类似的报告,但没有什么似乎明确(见下面的链接)。 有没有人从SQL 2000迁移到SQL 2008 R2后看到类似这样的错误? 链接: https://stackoverflow.com/questions/810673/connection-problems-with-sql-server-in-asp-net-applications-using-out-of-process http://blogs.msdn.com/b/spike/archive/2009/04/16/a-transport-level-error-has-occurred-when-sending-the-request-to-the-server-provider- TCP-提供商误差-0-AN-现有连接此结果强制地封闭由这-远程host.aspx

Akamai与小型/中型电子商务stream量的较小CDN? (caching,延迟,NetStorage)

我工作的中小型在线零售公司使用Akamai作为我们的静态图像CDN,但是我想知道它是否会伤害而不是帮助,如果不是最理想的,我们应该做些什么。 我们每月的stream量约为3M浏览量和40万独立访问者。 我们有不同的静态图像出现在我们的各种网页(几千种产品的每一个不同的图像等)。 问题是Akamai的服务器正在从原始服务器(我们自己托pipe)请求大约40%的浏览器请求的文件。 这意味着很多(在我看来)不必要的等待我们的客户:在返回给客户之前,40%的请求必须在Akamai和我们的来源之间往返。 服务器TTL不是问题; 他们都设置为365天。 所以它看起来像是 Akamai的边缘服务器并没有把我们的东西保存在caching中足够长的时间,而是将内容转换为比我们的stream量更高的内容,和/或 有很多Akamai边缘服务器(他们声称全球有70K +),每台服务器没有从我们的每月4.5万个访问者那里获得足够的stream量来构build大量的文件caching。 所以我开始想知道是否可以通过CDN服务器更好地服务于我们的服务器,我的想法是用更less的CDN服务器,我们的更多的图像将被更频繁地caching在每个服务器上,并且可能会更长时间地停留在caching中没有被换出。 另一方面,较less的服务器可能意味着不接近一台服务器的用户的更多延迟。 有两个基于Akamai的选项我们正在看,但还没有拉动触发器(还): 我们还没有使用他们的NetStorage服务,因为有一个技术障碍(如果我们朝这个方向走,这将成为我下一个SF问题的话题),而且有40%的时间还会有这个额外的往返边缘服务器和原点; 这只是Akamainetworking内部的往返行程,而不是我们单独托pipe的来源 – 可能会更快,但仍然是往返行程。 我们不支付Akamai的可选分层分销服务。 这可能会在很大程度上缓解这个问题,但是(1)它并不便宜,(2)40%的时间仍然会在边缘服务器和它的层级中心之间往返。 所以我的问题是: 你们是否认为将文件caching在较less的服务器上会更好一些,这是以某些用户的额外延迟为代价的; 或者是延迟比原始往返更大的问题? 如果我们使用NetStorage,有没有人对NetStorage“origin”的往返时间有多长? 我错过了什么? 我还有什么要考虑的呢?