rsync 可以支持一对多同步吗? [英] Can rsync support One to Many syncing?

问题描述

我是否可以使用 rsync 在同一服务器上 的数百个站点上同步我工作的模型"站点的更改?
我将更新通用模板文件和 JS 脚本.如果可能，我将如何设置?
(我在 Hostgator 专用服务器上，运行 Apache)

Can I sync changes from a "model" site that I work on, across hundreds of sites on the SAME server using rsync?
I would be updating common template files and JS scripts. If possible how would I set this up?
(I'm on a Hostgator Dedicated server, running Apache)

推荐答案

阅读我对下面已编辑问题的扩展答案.

最简单和天真的方法可能是设置一个脚本，该脚本只为您要同步的每个服务器运行 rsync.

The most trivial and naive approach would probably to set up a script that just runs rsync for every server you want to synchronize.

这在大多数情况下都很好，但我认为这不是您要找的东西，因为您自己会发现这一点...

This is fine in most cases, but I don't think this is what you are looking for, because you would have figured that out yourself...

这种方法也有以下缺点:

This method also has the following disadvantages:

• 一个服务器发送所有流量，没有级联.所以它是单点故障和瓶颈

• One server sends all the traffic, there is no cascading. So its a single point of failure and a bottleneck

这是非常低效的.rsync 是一个很好的工具，但是解析文件列表和检查差异并不是很快，如果你想同步数百台服务器

It is very inefficient. Rsync is a great tool, but parsing the file list and checking differences is not really quick, if you want to synchronize hundreds of servers

但是你能做什么?

为多个服务器配置 rsync 显然是最简单的方法.所以你应该从这个开始，优化你的问题所在.

Configuring rsync for multiple servers is obviously the easiest way to go. So you should start with that and optimize where your problems are.

例如，您可以通过使用正确的文件系统来加快速度.XFS 可能比 Ext3 快 50 倍.

You can speed it up for example by using the right Filesystem. XFS will probably be like 50 times faster than Ext3.

您还可以使用更强大的工具 unison，并在缓存中保留文件列表.

You can also use unison which is bit more powerful tool and keeps a list of Files in cache.

您也可以设置级联(服务器 A 同步到服务器 B，同步到服务器 C).

You can also set up a cascade (Server A synchronizing to Server B synchronizing to Server C).

您也可以设置拉动而不是由您的客户推动.您可以有一个子域，它是负载平衡器的入口点，在那里您有 1 个或多个服务器，通过从源服务器推送来同步这些服务器.

You could also set up pulling rather than pushing by you clients. You could have a sub domain for that which is point of entry to a load balancer, where you have 1 or more servers behind which you synchronize by pushing from your source server.

我之所以告诉你这一切，是因为没有完美的方法，你必须根据自己的需要去想办法.

The reason why I am telling you all this is because there is not the perfect way to go, you have to figure it out depending on your needs.

不过，我绝对建议您研究一下 GIT.

However I would definitely recommend looking into GIT.

Git 是一个非常强大和高效的版本控制系统.

Git is a version control system that is very powerful and efficient.

您可以创建一个 git 存储库并推送到您的客户端计算机.

You could create a git repository and push to your client machines.

它运行良好、高效且灵活且可扩展，因此您几乎可以在此结构上构建任何东西，包括分布式文件系统、级联、负载平衡等.

It works very well and efficient and is flexible and scalable, so you can build almost anything on this structure including distributed file systems, cascades, loadbalancing etc.

希望我在您可以研究的正确方向上给了您一些观点.

Hope I gave you some points in the right directions you can look into.

所以看起来您想要在同一台服务器上同步更改 - 甚至是同一个硬盘(我不知道，但对于您拥有的可能性非常重要).

So looks like you want to synchronize changes on the same server - or even same hard disc (which I don't know, but is very important for the possibilities that you have).

基本上都是一样的.插入-覆盖-删除...Rsync 也是一个非常棒的工具，因为它可以增量地传输更改.不仅恢复中断的传输".

Well basically its all the same. Insert - Overwrite - Delete ... Rsync is also a very great tool for that because it transfers changes incremental. Not only "resumes broken transfers".

但我会说这完全取决于内容.

But i would say it completely depends on the content.

如果你有很多小文件，比如你说的模板、javascript等，rsync可能会很慢.完全删除源文件夹并再次将文件复制到那里可能会更快.因此 rsync(或任何其他工具)不必检查所有文件的更改等.

If you have a lot of small files, such as you say template, javascript, etc, rsync may be very slow. It might even faster to completely delete the source folder and copy the files there again. So rsync (or any other tool) doesn't have to check all files for changes etc.

您也可以使用 -rf 开关复制所有内容，这样所有内容都将被覆盖，但是您可能会在那里删除旧文件.

You can also just copy everything with the -rf switch so everything will be overwritten, but then you could have old files there that got deleted.

我也知道很多使用 subversion 完成此类事情的情况，因为人们觉得拥有更多控制权或我不知道的东西.它也更灵活.

I also know many cases where such stuff is done using subversion, because people feel like having more control or something I dunno. Its also more flexible.

但是，您应该考虑一件事:

However there is one thing that you should think of:

有共享数据的概念.

有符号链接和硬链接.

你可以把它们放在文件和文件夹上(硬链接只放在文件上.我不知道为什么).

You can put them on files and folders (hard links only on files. I dunno why).

如果您将符号链接 A 放在目标 B 上，该文件看起来像符号链接一样被定位和命名，但背后的资源在某处完全不同.但应用程序可以区分.例如，Apache 必须配置为遵循符号链接(否则这将是一个安全问题).

If you put a Symlink A on a target B the file looks like being located and named like the symlink, but the resource behind is somewhere completely different. But applications CAN distinguish. Apache for example has to be configured to follow symlinks (otherwise it would be a security issue).

因此，如果您的更改都在一个文件夹中，您只需放置一个名为该文件夹的符号链接，指向您的文件夹，您就不必担心再次同步，因为它们共享完全相同的资源.

So if you changes are all in one folder you could just put a symlink called like that folder, pointing to your folder there, and you never have to worry about synchronizing again, because they share the very same resource.

但是，您也有理由不想这样做:

However there are reasons why you wouldn't want to do so:

• 它们看起来不一样.- 这听起来很荒谬，但实际上，这是人们不喜欢符号链接的最常见原因.人们抱怨是因为他们在他们的程序中看起来很奇怪"或其他什么.

• They look different. -that sounds absurd, but really, that is the most common reason why people don't like symlinks. People are complaining because they "look so weird in their program" or whatever.

符号链接在某些功能上受到限制，但因此具有其他巨大的优势.像跨文件系统指向等.但是.几乎所有的缺点都可以很好地处理并在您的应用程序中解决.可悲的事实是，符号链接是 linux oses 和文件系统的基本特征，但是在开发应用程序时有时会忘记它们的存在.就像开发火车却忘了也有长腿的人什么的……

Symlinks are limited in certain capabilities but therefore have other huge advantages. Like cross-filesystem pointing etc. However. Almost every disadvantage can be quite well dealed with and be worked around in your application. The pitiful truth is that symlinks are a fundamental feature of linux oses and filesystems, but their existence is sometimes forgotten when developing an application. Its like developing a train but forgetting that there are also people with long legs or something...

另一方面，硬链接确实看起来像文件，因为它们是文件.

Hardlinks on the other hand do exactly look like files because they are files.

每个指向一个文件的硬链接就是那个文件.

And every hardlink pointing to one file is that very file.

听起来令人困惑，但请按以下方式思考:

It sounds confusing but think of it as follows:

每个文件都是光盘上的一些数据.然后有一些 inode 指针，它位于某个目录中，某个名称指向该资源.

Every file is some data on the disc. Then there is some inode pointer which inside some directory with some name pointing to that resource.

硬链接就是这样.文件只有多个列表".

Hardlinks are just that. There are just multiple "listings" of the file.

因此，它们共享相同的读锁，一起被修改/删除/等等.

As a consequence they share the same read lock, get modified/deleted/etc together.

然而，这当然只能在一个文件系统/设备上完成，而不是跨设备.

This however can of course only be done on one filesystem/device and not cross-device wise.

链接有一些很大的优势.它们非常明显:

Links have some big advantages. They are quite obvious:

您没有重复的数据.这消除了不一致的可能性，您不必更新并且需要更少的磁盘空间.

You don't have duplicate data. Which eliminates the potential for inconsistencies and you don't have to update and need less space on the disk.

然而，这有时具有更重要的意义.

This however has sometimes far more significance.

例如，如果您运行多个网站并且所有网站都使用 Zend 框架.

For example if you run multiple website and all of them use the Zend Framework.

这是一个庞大的框架，它的操作码缓存会填满你的 50 兆内存或其他东西.

This is shitload huge framework and the opcode caching of it will fill up like 50 megs of your ram or something.

如果您的网站有相同的 zend 库文件夹，则只需一次.

If you have the same zend library folder for your websites, you need that only once.

这篇关于rsync 可以支持一对多同步吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！