calendarserver_purge_* tools
calendarserver_upgrade - for upgrading data in-place when a new server version has been installed with newer schema
backup and restore of the all the service data. This is not limited to only the stuff in Postgres, but also possibly service configs, file attachments, and directory services data.
calendarserver_verify_data for detecting and fixing problems in the data itself, which can happen for a variety of reasons such as bugs or bad clients
monitoring and measurement tools to help you evaluate performance and do scalability planning. Some of these are in ‘bin’, some are under ‘contrib’. Eventually I will write some actual documentation for these...

-dre

On Feb 18, 2015, at 3:37 PM, Andre LaBranche <dre@apple.com> wrote:

On Feb 18, 2015, at 1:04 PM, Gaurav Jain <monkeyfdude@gmail.com> wrote:

My question is:

* Has CalendarSever-5.2.2 been used in PROD deployments?
* Since I don't have scaling issues, is it ok to use XMLDirectoryService for like 1000 accounts?

Hello,

Calendar Server can be (and is, in rare instances) deployed in a high-availability (HA) configuration, which can also be used to scale. Check out the following document, which identifies the important parts of a multi-server configuration.

http://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Admin/MultiServerDeployment.rst

Removing all single points of failure would require implementing HA / redundancy for each of the items listed in that document, which is beyond the scope of our documentation, but should be a familiar process for anybody who has ever implemented HA.

XMLDirectoryService is probably the most scalable directory service we support, due to its simplicity. If it meets your needs, I can’t think of a reason to switch away from it.

-dre
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/calendarserver-users