Pros and cons of a multisite installation

Given that a multisite installation of discourse uses about the same resources as an ordinary install with the same traffic , I wonder what exactly the downsides are, apart from a more complicated setup procedure.

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?

「いいね!」 6

An obvious one is that if one of your sites is down, all of your sites are down (right?)

Yes

「いいね!」 1

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 :wink:

「いいね!」 14

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
  • Some plugins are incompatible with multisite
「いいね!」 8

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?

「いいね!」 3

Very easily put: there is a (albeit small) memory penalty that is proportional to the amount of multisite forums.

Correct.

Most plugins just turn off their functionality but they are still loaded into memory. So there is a (small) memory and performance penalty there.

This is not about the nginx discourse.conf but about the Discourse one. I think it’s generated out of app.yml.

Trial and error…

「いいね!」 4

多言語(en-USだけでなく)をサポートするマルチサイトは可能でしょうか?

それとも、各Discourseマルチサイトはメイン設定の言語のみをサポートできますか?

n8n コミュニティ がそのアプローチに従っているようですが、SSO をブログや他のドメイン/アプリ内で使用する予定がある場合、欠点は関連する可能性があります。

はい、可能です。

詳しく教えていただけますか?

これは5年前のことです。マルチサイトで動作するプラグインとそうでないプラグインを確認する方法に変更はありますか?

もし興味のある方がいれば、私がすべてのサイトで使用しているプラグインは次のとおりです。

      - git clone https://github.com/focallocal/dcs-discourse-plugin.git
      - git clone https://github.com/discourse/discourse-assign.git
      - git clone https://github.com/hnb-ku/discourse-custom-hamburger-links
      - git clone https://github.com/paviliondev/discourse-custom-wizard.git
      - git clone https://github.com/paviliondev/discourse-events.git
      - git clone https://github.com/discourse/discourse-kanban-theme.git
      - git clone https://github.com/discourse/discourse-data-explorer
      - git clone https://github.com/discourse/discourse-solved
      - git clone https://github.com/discourse/discourse-akismet
      - git clone https://github.com/discourse/discourse-post-voting
      - git clone https://github.com/discourse/discourse-docs
      - git clone https://github.com/discourse/discourse-docs-card-filter
      - git clone https://github.com/discourse/discourse-category-experts
      - git clone https://github.com/discourse/discourse-cakeday
      - git clone https://github.com/discourse/discourse-code-review

テーマコンポーネントがいくつか誤って含まれているようですが?

「いいね!」 3

ああ、そうですね、不注意でした。でも、そのままでも問題なく動作するようです :sweat_smile:

私はよく、他に何もすることがなくなった後、本来ならもう寝ているはずの時間にサイトのメンテナンスをします。

ご指摘ありがとうございます。

「いいね!」 1

「最初の」インスタンスを決定するのは何ですか?標準のインストールをダミーの最初のインスタンスを持つマルチサイトに変換するにはどうすればよいですか?

一番簡単なのは、私のアドバイスを無視して、既存のインストールが最初のものであるという事実を受け入れることです :slight_smile:

もし変換したいのであれば、バックアップを作成し、最初のダミーインスタンスと既存のドメイン用の最初の「実際の」マルチサイトインスタンスを含む新しいマルチサイトインストールをセットアップしてから、バックアップを復元することができます。

「いいね!」 1