Clarification on Visibility database

Community Support
,
1

Hi,

If I do not intend to use Advanced Visibility of Temporal, is it still mandatory to provide Cassandra Visibility parameters while configuring temporal using helm chart? Can I just provide core database related cassandra properties and setup temporal cluster without Visibility database?
Will I get Standard Visibility features even when Visibility database as well as Elastic Search integration is not done…?

2

@tihomir Can you please clarify on this.

3

You cannot turn off visibility. You can define to use standard and/or enhanced visibility with Elasticsearch.

In dynamic config system.advancedVisibilityWritingMode can be set to:

  1. off - visibility records are not written to enhanced visibility store
  2. on - visibility records are written to only enhanced visibility store
  3. dual - write to both visibility store and enhanced visibility store

If you set up your cluster with Elasticsearch as enhanced visibility store then there should be no need to also set up cassandra/mysql/postesql visibility settings.

4

Thanks! Btw, what is the default value of system.advancedVisibilityWritingMode?

5

Depends on your cluster configuration, see here and here.

So its dependent on your persistence->advancedVisibilityStore config being defined or not if you do not set it explicitly.

1 Like
6

@tihomir Quick question on this. Is there a recommendation from temporal on this? If we have ES set up - is there any downside of writing only to ES and not to the visibility db?

7

For production use cases where high loads are common ES is the recommended way for storing visibility records.

8

Thanks and we can choose to write only to ES right? I am assuming that there is no known downside of choosing to write only to ES.

9

Yes, if you configure advancedVisibilityStore in your persistence config it should default to writing to advanced visibility store only (same as setting system.advancedVisibilityWritingMode to on in dynamic config)

1 Like
10

@tihomir I have a follow-up question on this topic. Why do we “have to” have visibility? I thought it was an optional part that is only needed if the SDK side wants to have a customized query.

11

I think honest answer is that visibility is just part of the Temporal service experience (ui and some features like batch operations would not be available without it).

Even tho service itself could work without visibility configured, don’t think this has been tested so removing it completely would not be best idea.

1 Like
12

image
image1920×874 186 KB

Hey, I have a follow-up question.

  1. My understanding of the previous discussions is that if we use advanced visibility, standard visibility is not needed.
  2. But here at the helm chart, the visibility should refer to Cassandra or SqlDB, or else the helper will raise an error.

So I am confused a bit here.

  • I read some source code (config part). So does leaving the visibility host and port to “” (empty string) make sense?
  • Or the helm chart doesn’t consider this case?
  • Or the we still have to connect the visibility to some DB even if we are using ES visibility?