Skip to content

AEM Publisher Refresh Procedure

Step-by-step Procedure (Publisher)

  • This sync process is somewhat faster than the author sync process (mainly because it contains much less data).
  • Again, its best to do this process during off hours, generally overnight.
  • See rsync for details.

On the target machine:

# Publisher instances [2x] (ex. cmsa-pprd-02.db.vt.edu, cmsa-pprd-03.db.vt.edu)
aemctl-publisher stop
rsync --daemon --config ~/rsyncd.conf --port 4500 --no-detach

On the source machine:

rsync -rv --del /apps/cms/var/data/aem64-publish/crx-quickstart/repository/datastore/ rsync://cms@cmsa-pprd-02.db.vt.edu:4500/datastore/

The first pprd publisher should be cloned from a production publisher, and the second publisher can be cloned from the first.

  1. Shut down TARGET instance
aem-sequencer stop
  1. Move the CRX-Quickstart

Note this is different from the Author procedure. In the Publisher case, the (very large) datastore lives in the crx-quickstart, not on a NAS volume. We will move the quickstart directory, restore the backup, then move the datastore into the right place.

aemctl-publish stop
mv /apps/cms/var/data/aem64-publish/crx-quickstart{,-pre-refresh}
  1. Untar latest production backup to TARGET
cd /apps/cms/var/data/aem64-publish
tar xvf /apps/mounts/cmsbinary/prod_segmentstore/{cmsa-prod-02}/crx-quickstart-{date}.tar
  1. Move the datastore into the current repository
mv /apps/cms/var/data/aem64-publish/crx-quickstart-pre-refresh/repository/datastore/ /apps/cms/var/data/aem64-publish/crx-quickstart/repository/
  1. Create the logs directory
mkdir /apps/cms/var/data/aem64-publish/crx-quickstart/logs

Start the Instance

  1. Start the PUBLISHER instance on TARGET

Log in to CRX/DE (${TARGET}/crx/de/index.jsp) as admin or into "CRX Explorer" (${TARGET}/crx/explorer/index.jsp) {remember this will have the SOURCEs password}

Sometimes you will be sent to the orange "Welcome to Adobe Experience Manager" login at ${TARGET}/libs/granite/core/content/login.html. This login will work for local accounts only, i.o.w. admin, cmsadmin, etc.

Replication Agents on Publishers are responsible for flushing (invalidating) the Dispatcher cache on their respective dispatchers. Dispatchers and publishers work in pairs, according to even-ness or odd-ness of their machine numbers. In other words, cmsa-prod-02 (even) renders pages for the even dispatchers (cmsw-prod-02 and cmsw-prod-04).

  • Go to Replication Agents on publish (${TARGET}/miscadmin#/etc/replication/agents.publish)

Replication Agents on Publisher

  • Update or Deactivate flush-01 through flush-04 by double-clicking on the row.

  • Under Settings -> Edit (yes, edit is a button that changes when you hover over it).

Dispatcher Flush

Note that this queue is blocked... why is it blocked?

The queue is blocked because these queue items are production artifacts that we imported into this non-production system through the backup and restore process. We also imported the production configuration through that process. So these are items that the non-production publisher is trying to send to the production tier. The production tier is (correctly) rejecting replication items from the non-production tier.

Clear any queued items with the 'Clear' button at the top of the queue list.

  • On the Transport tab, change the URI

Replication Agent Settings