An obvious one is that if one of your sites is down, all of your sites are down (right?). But what about support, for example? If I search meta for a solution to an issue and find something, will it automatically apply to my multisite install, even though the original topic doesn’t explicitly deal with multisite?
Typically yes – however, for some steps, you’ll need to make sure you work on the correct instance. The key is to set an environment variable like RAILS_DB=myfancypantsinstance1 e.g. when entering the rails console.
This is why I recommend making the first instance on a multisite host a test instance: If you ever forget to specify the instance, you’ll target your test instance, which is probably safer than working with a production instance by accident
That is not entirely true: for each Unicorn process there can a separate database connection for each site in the multisite. So 5 Unicorns, 1 Sidekiq and 5 sites = 30 Postgres server processes.
Some other disadvantages / things you need to be aware of with multisite:
Sidekiq is shared and /sidekiq is only available on the master site
All plugins are shared, there can not be separate plugin choices
discourse.conf is shared so there can only be one mail server
I don’t understand a word what you are saying, but that is entirely my fault. I understand, though, that you are counting software processes and I have no idea how these translate into hardware recourse requirements. Could you elaborate?
I understand that this can be a disadvantage from the perspective of a (commercial) hoster because your clients wont have access to /sidekiq on their respective sites and if you give them access to the mastersite they will possibly see more than they want or should see, right? But if all sites are mine, it probably doesn’t matter, right?
Very important point, thanks for bringing that up! However, provided that all installed plugins have a switch to turn them off, it doesn’t really matter, does it?
Wait, the only one of my instance where I did something with a discourse.conf file is the one where I have discourse behind a reverse proxy and there is nothing about email in that file.
How do I know which ones? Trial and error? Or, since this also about future compatibility, what type of plugins are likely to be incompatible?
Es scheint, dass n8n Community diesem Ansatz folgt. Der Nachteil könnte mit SSO zusammenhängen, wenn Sie planen, es innerhalb eines Blogs oder einer anderen Domain/App zu verwenden.
Was bestimmt, welche die „erste“ Instanz ist? Wie geht man vor, um eine Standardinstallation in eine Multi-Site-Installation mit einer Dummy-ersten Instanz umzuwandeln?
Die einfachste Option ist, meinen Rat zu ignorieren und damit zu leben, dass Ihre bestehende Installation die erste ist
Wenn Sie konvertieren möchten, könnten Sie jederzeit ein Backup erstellen, Ihre neue Multisite-Installation einrichten, einschließlich der ersten Dummy-Instanz und Ihrer ersten „echten“ Multisite-Instanz für die bestehende Domain, und dann das Backup wiederherstellen.
