I've got two app servers that are load balanced by a third server. Right now I've got Magento's cron setup on just one of the app servers. The problem is that I want to turn on Magento sitemap cron job. However, since cron is only setup on one app server, the sitemap will only be generated on one app server.

Is there any danger in configuring Magento's cron scheduler on both of the app servers? Will that create any race conditions, conflicts, duplicate tasks, etc? Or what is the standard for handling Magento's cron system in a clustered environment?

  • In the same scenario I've got duplicated emails. – lrkwz May 9 '16 at 10:28

I wouldn't run the task on both servers. It will probably cause unexpected issues. The easiest way to fix this is probably using scp to copy the generated sitemap to the other server.

After running the cron you would want to execute a command like

scp /path/to/sitemap.xml [username]@[second server ip]:/destination/of/sitemap.xml


Do not run cron on both servers.

Currently in my work, I have a similar situation, with Varnish (cache and load balance) + 4 EC2 servers (Nginx) + RDS + Redis (for session and cache). One Ec2 running just to adminhtml panel (admin with a subdomain e.g. admin.mystore.com.br/admin) and three EC2 to store frontend (www.mystore.com.br). We work on all the admin server and update the remaining server with rsync 2 in 2 minutes.

All our crons runs on the administration server, so in this case the sitemap.xml always created at admin server and replicated to other.

This approach makes it more scalable solution than pure rsync (without a master server - "server admin" in my case) or scp because the number of web server that you own can raise all you want.

Of course, in a cluster solution, there is many "variables" to consider, for example, remember to synchronize the media folder because if you do not have a centralized admin will have problems because when uploading an image in admin panel, you'll be saving the image only in one of the servers, so 404 for many users when they hit other server.

Finally, if you want just a solution to your current cluster, use scp like Sander described in first answer.

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.