在我的发布场景中,我们有多个部署者将内容推送到文件系统和数据库(代理)。页面和二进制文件放在文件系统上,其他一切都放在 Broker 中。我们有一名部署人员将内容放入数据库。这是推荐的最佳做法吗?
如果所有部署器中的存储配置也将内容放入数据库中,那么 Tridion 是如何处理的呢?这会导致重复条目、锁定失败等吗?
恐怕在撰写本文时,我无法访问环境来测试它是如何工作的。
在我的发布场景中,我们有多个部署者将内容推送到文件系统和数据库(代理)。页面和二进制文件放在文件系统上,其他一切都放在 Broker 中。我们有一名部署人员将内容放入数据库。这是推荐的最佳做法吗?
如果所有部署器中的存储配置也将内容放入数据库中,那么 Tridion 是如何处理的呢?这会导致重复条目、锁定失败等吗?
恐怕在撰写本文时,我无法访问环境来测试它是如何工作的。
SDL 最佳实践是在部署者和发布者之间建立一对一的关系;这意味着只要两个部署者不发布相同的内容(来自同一个出版物),那么他们就不会发生冲突,如果是文件系统,则部署的站点之间存在分离,例如 www/pub1 和 www/pub2。
您对场景的解释需要一些额外的信息才能使其完整,但听起来很可能有多个代理数据库(尽管托管在单个数据库服务器上)。这是处理网络服务器上的多个文件系统并结合单个数据库服务器时最常见的设置。
我个人不喜欢这种设置,因为我认为将文件系统内容托管在共享位置并共享单个数据库会更好。或者最好还是将所有内容部署到数据库并使用 DD4T/CWA 之类的东西。
我已经看到(甚至根据客户限制推荐)类似的配置,您将多个部署器配置为给定目标的目的地。
只有一个部署者可以为同一事务写入数据库,否则您将遇到并发问题。因此,一个部署者写入数据库,而所有其他部署者写入文件系统。
所有代理/Web 应用程序都配置为从数据库中读取。
这解决了部署到使用共享文件系统(首选方法)不可行的多个服务器和/或数据中心的问题 - 无论是出于成本还是任何其他原因)。
简而言之 - 不是最佳实践,但众所周知它可以工作。
Julian 和 Nuno 的方法涵盖了大多数常见场景。确实,单个数据库是单点故障,但在许多安装中,您需要在同一数据库服务器上运行多个模式,因此即使您有多个“代理数据库”,您仍然会遇到单点故障。
另一个需要考虑的替代方案是完全独立的交付节点。这甚至可能意味着在您的展示盒上运行一个数据库服务器。如今,无论如何它都是虚拟的,因此您可以运行单独的小型数据库服务器。(许可成本将是一个重要的制约因素)
每个交付服务器都有自己的数据库和文件系统。根据您想要的数量,您可能不想设置多个目标/部署器,因此您部署到一个,并使用文件系统复制和数据库日志传送将内容镜像到其余部分。
当然,您可以配置两个(或三个)部署系统以实现冗余,假设您可以管理所有集群等。
好吧——坦白说——我从来没有像这样建造过,但我相当肯定这种设计的元素会随着虚拟化的增加和支持它的许可模型变得更加普遍。(也许我们必须等待 Tridion 支持开源数据库!)