6

We have a scaled-out web application architecture with multiple servers in a load-balance. These nodes share a common broker database. Since upgrading to 2011 (currently SP1), When a file-system asset is unpublished, this succeeds on the first node, but not on the others. Our current thinking is that this first undeployment alters the state of the broker database in a way that prevents undeployments of the same asset from other nodes from taking place.

Obvious solutions would be to give each node its own database, or to arrange for a single deployment destination with further replications placed out of the responsibility of Tridion. Neither of these is attractive, as the system is already deployed to production, and large infrastructure changes would be difficult.

Is this a known behaviour? Does our current thinking make sense? Can you suggest a solution or workaround that would match these needs?

  • 1
    Yes as per my knowledge it is a known behaviour and your current thinking absolute makes sense. I have been through the above mentioned scenario and used the second solution you have mentioned in the question - Replication to sync through all the servers – Pankaj Gaur Jan 15 '14 at 15:34
5

A scenario you could try is:

  • Have first deployer configured for deploy in File system and Database

  • Have second deployer configured for deploy in File system only.

  • Group both deployer destinations under the same Publication Target

In that case there is no risk of interference between both, as only one interacts with the Broker Database.

Only thing is that you will have some info (as metadata) that will be published in the file system and never used.

Keep your Web applications with same configuration as today (Using FS and Broker DB). I would suggest other architectures also, as this could have some problems in terms of high availability for the deployer, but based on the fact that is a production system and the impact of introducing a new architecture, please evaluate this option, as seems for me the most easy to achieve in the current situation.

4

Different Deployers sharing a common Broker database is not supported as far as I can recall, unless each Deployer is configured to only handle a specific Publication. The reasoning behind it is the obvious locking issues you can come in, or similar to what you describe. So yes the behavior is known and your thinking makes sense.

I find the wording you choose rather funny:

...further replications placed out of the responsibility of Tridion...

Replication has never been a responsibility of Tridion, since Tridion is a CMS and not a replication server or cluster manager. Unfortunately solutions like the one you describe have been configured often and never really work to anyone's satisfaction.

I would really suggest to change the architecture, and make it a proper one. Choises would be:

  1. Put the Deployers behind a proper Load Balancer so that only one Deployer is actively handling the request and let the replication in the hands of proper Replication software

  2. Give each node its own Broker database (still not a good solution since when a node goes down, it will be out of sync unless all items are manually republished to it).

Unfortunately that means there is no workaround matching your needs as far as I know of.

0

I am facing the same issue.

From an architural or infrastructural point of view, a nice solution is to have one or two destinations, for a shared filesystem and brokerdatabase. Serveral webservers used the shared filesystem. This is a clean architecture. Metadata is written to a databases, files are written to a/one shared filesystem (RAID), several webservers for loadsharing use a central filesystem and each of these building blocks can be tuned/tailored to its need.

Our current solution are three destinations to three different servers, of which only one is configured to write to the (shared) brokerdatabase, but all three write to their own filesystem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.