--
You received this message because you are subscribed to the Google Groups "Quartz.NET" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quartznet+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quartznet/040b8336-8cb5-4de2-b8d3-e52f024a5468%40googlegroups.com.
Yes it should be fine to have two clusters against shared database tables as long as scheduler names are different. Database queries are isolated by checking scheduler's name in every query. Quartz is more concerned about other configuration (make sure all nodes are configured to be clustered, time-synced etc).I think the question boils down to how you want to manage backups and scale. The clusters are competing of I/O and other database resources. I'm not a postgres expert so can't say whether having separate databases or schemas for clusters would yield better results (instead of different tables in same db).-Marko
On Thu, May 21, 2020 at 8:20 AM Seth Goldstein <seth.d....@gmail.com> wrote:
--We are evaluating using this setup:
- a single postgresql database with a single set of qrtz_ tables
- a cluster of 3 scheduler instances all with instance name "A" using the qrtz_ tables in the postgres database
- a second cluster of 3 scheduler instances all with instance name "B" using the same qrtz_ table in the same postgres database
Are there any concerns with this setup?We believe that there should not be an issue with data validity using the same qrtz_ tables as long as the 2 independent clusters have their own unique instance names. Is our belief correct?Is there a strong preference for using a different set of tables with a different prefix for the different clusters?
You received this message because you are subscribed to the Google Groups "Quartz.NET" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quar...@googlegroups.com.