Controlling access.log in a bucket

[ota]

I am having trouble with the “DCP Replication Items Remaining” value sometimes increasing at 11:00.
Since we are using the durability level of majorityAndPersistActive, when this value increases, writing temporarily fails.

After investigating this phenomenon, I found that it occurs when the access.log in the bucket is replaced.
The specific path is as follows:

couchbase/data//access.log.0
・
・
・
couchbase/data//access.log.7

Is it possible to control the size or replacement time of this log file?
I couldn’t find anything about this in the documentation, so I’d like to ask.

The version is Community Edition 6.6.0 build 7909.

Since it may not be conveyed by machine translation, I will also post the original text.

— Start
時々11時に"DCP Replication Items Remaining"の値が増加する現象に悩まされています。
当方はDurability LevelをmajorityAndPersistActiveで運用している為、この値が上昇すると一時的に書き込みに失敗します。

こちらの現象について調べたところ、バケット内に存在するaccess.logが入れ替わった際に発生することが判明しました。
具体的なパスは下記の通りとなります。
couchbase/data//access.log.0
・
・
・
couchbase/data//access.log.7

このログファイルですが、サイズや入れ替わりの時間を制御することは出来ますでしょうか。
ドキュメントを見る限りこちらについて言及された内容が見つからなかったので質問させて頂きます。

なお、バージョンはCommunity Edition 6.6.0 build 7909となります。
— End

[mreiche]

Manage Logging | Couchbase Docs

the ‘static_config’ file is

<couchbase-install-dir>/Contents/Resources/couchbase-core/etc/couchbase/static_config.in

[ota]

Dear mreiche,

Thank you very much for your reply.
I also appreciate you pointing me to the relevant part of the document.

I would like to confirm just to be sure, but the document you provided is about the settings for the files output under
<couchbase-install-dir>/var/lib/couchbase/logs.

What I want to know this time is the setting for
<couchbase-install-dir>/var/lib/couchbase/data/<bucket-name>/access.log.<number>.
※This path was missing from the first post. I apologize for the confusion.

That is because I understand that if “static_config” is not changed, the setting for “disk_sink_opts” is reflected, but the number of “num_files” does not match for “access.log” that I asked about.
Also, the timestamp behavior is different as shown below, so I suspect it is different from the setting you provided.

$ cd <couchbase-install-dir>/var/lib/couchbase/logs
$ ls -l
 ・
 ・
 ・
-rw-rw---- 1 couchbase couchbase 14642573 May 31 11:39 stats.log
-rw-rw---- 1 couchbase couchbase 6615779 May 31 06:18 stats.log.1.gz
-rw-rw---- 1 couchbase couchbase 6614926 May 30 14:55 stats.log.2.gz
-rw-rw---- 1 couchbase couchbase 6634323 May 29 23:34 stats.log.3.gz
-rw-rw---- 1 couchbase couchbase 6610991 May 29 08:11 stats.log.4.gz
-rw-rw---- 1 couchbase couchbase 6619879 May 28 16:50 stats.log.5.gz
-rw-rw---- 1 couchbase couchbase 6636353 May 28 01:28 stats.log.6.gz
-rw-rw---- 1 couchbase couchbase 6606611 May 27 10:05 stats.log.7.gz
-rw-rw---- 1 couchbase couchbase 6601604 May 26 18:42 stats.log.8.gz
-rw-rw---- 1 couchbase couchbase 6606600 May 26 03:19 stats.log.9.gz
 ・
 ・
 ・
$ cd <couchbase-install-dir>/var/lib/couchbase/data/<bucket-name>
$ ls -l
 ・
 ・
 ・
-rw-rw---- 1 couchbase couchbase 39968768 May 31 11:00 access.log.0
-rw-rw---- 1 couchbase couchbase 39948288 May 30 11:01 access.log.0.old
-rw-rw---- 1 couchbase couchbase 39223296 May 31 11:00 access.log.1
-rw-rw---- 1 couchbase couchbase 39206912 May 30 11:01 access.log.1.old
-rw-rw---- 1 couchbase couchbase 40779776 May 31 11:00 access.log.2
-rw-rw---- 1 couchbase couchbase 40759296 May 30 11:01 access.log.2.old
-rw-rw---- 1 couchbase couchbase 39161856 May 31 11:00 access.log.3
-rw-rw---- 1 couchbase couchbase 39145472 May 30 11:01 access.log.3.old
-rw-rw---- 1 couchbase couchbase 41549824 May 31 11:00 access.log.4
-rw-rw---- 1 couchbase couchbase 41533440 May 30 11:01 access.log.4.old
-rw-rw---- 1 couchbase couchbase 40882176 May 31 11:00 access.log.5
-rw-rw---- 1 couchbase couchbase 40865792 May 30 11:01 access.log.5.old
-rw-rw---- 1 couchbase couchbase 39137280 May 31 11:00 access.log.6
-rw-rw---- 1 couchbase couchbase 39116800 May 30 11:01 access.log.6.old
-rw-rw---- 1 couchbase couchbase 39985152 May 31 11:00 access.log.7
-rw-rw---- 1 couchbase couchbase 39964672 May 30 11:01 access.log.7.old
 ・
 ・
 ・

We apologize for the inconvenience, but please check.
Kind Regards,

Since it may not be conveyed by machine translation, I will also post the original text.

—Start
mreiche様

ご返信頂き、誠にありがとうございます。
また、ドキュメントの該当箇所を教えて頂き感謝致します。

念の為確認させて頂きたいのですが、ご教示頂いたドキュメントは
<couchbase-install-dir>/var/lib/couchbase/logs
以下に出力されるファイルの設定ではないでしょうか。

私が今回知りたいのは
<couchbase-install-dir>/var/lib/couchbase/data/<bucket-name>/access.log.<number>
の設定になります。
※最初に記載した書き込みで、こちらのパスが欠けておりました。混乱を招き申し訳ございません。

といいますのも、"static_config"を変更していない場合"disk_sink_opts"の設定が反映されると認識しているのですが、私が質問した"access.log"については"num_files"の数が合いません。
また、下記のようにタイムスタンプの動きも違う為、ご案内頂いた設定とは別なのではないかと推察しております。

$ cd <couchbase-install-dir>/var/lib/couchbase/logs
$ ls -l
 ・
 ・
 ・
-rw-rw---- 1 couchbase couchbase 14642573  5月 31 11:39 stats.log
-rw-rw---- 1 couchbase couchbase  6615779  5月 31 06:18 stats.log.1.gz
-rw-rw---- 1 couchbase couchbase  6614926  5月 30 14:55 stats.log.2.gz
-rw-rw---- 1 couchbase couchbase  6634323  5月 29 23:34 stats.log.3.gz
-rw-rw---- 1 couchbase couchbase  6610991  5月 29 08:11 stats.log.4.gz
-rw-rw---- 1 couchbase couchbase  6619879  5月 28 16:50 stats.log.5.gz
-rw-rw---- 1 couchbase couchbase  6636353  5月 28 01:28 stats.log.6.gz
-rw-rw---- 1 couchbase couchbase  6606611  5月 27 10:05 stats.log.7.gz
-rw-rw---- 1 couchbase couchbase  6601604  5月 26 18:42 stats.log.8.gz
-rw-rw---- 1 couchbase couchbase  6606600  5月 26 03:19 stats.log.9.gz
 ・
 ・
 ・
$ cd <couchbase-install-dir>/var/lib/couchbase/data/<bucket-name>
$ ls -l
 ・
 ・
 ・
-rw-rw---- 1 couchbase couchbase 39968768  5月 31 11:00 access.log.0
-rw-rw---- 1 couchbase couchbase 39948288  5月 30 11:01 access.log.0.old
-rw-rw---- 1 couchbase couchbase 39223296  5月 31 11:00 access.log.1
-rw-rw---- 1 couchbase couchbase 39206912  5月 30 11:01 access.log.1.old
-rw-rw---- 1 couchbase couchbase 40779776  5月 31 11:00 access.log.2
-rw-rw---- 1 couchbase couchbase 40759296  5月 30 11:01 access.log.2.old
-rw-rw---- 1 couchbase couchbase 39161856  5月 31 11:00 access.log.3
-rw-rw---- 1 couchbase couchbase 39145472  5月 30 11:01 access.log.3.old
-rw-rw---- 1 couchbase couchbase 41549824  5月 31 11:00 access.log.4
-rw-rw---- 1 couchbase couchbase 41533440  5月 30 11:01 access.log.4.old
-rw-rw---- 1 couchbase couchbase 40882176  5月 31 11:00 access.log.5
-rw-rw---- 1 couchbase couchbase 40865792  5月 30 11:01 access.log.5.old
-rw-rw---- 1 couchbase couchbase 39137280  5月 31 11:00 access.log.6
-rw-rw---- 1 couchbase couchbase 39116800  5月 30 11:01 access.log.6.old
-rw-rw---- 1 couchbase couchbase 39985152  5月 31 11:00 access.log.7
-rw-rw---- 1 couchbase couchbase 39964672  5月 30 11:01 access.log.7.old
 ・
 ・
 ・

大変お手数ですが、ご確認の程よろしくお願い致します。
—End

[mreiche]

I suggest upgrading to the latest 7.x version as that might behave better.

The access scanner can be turned off completely with :

cbepctl -u <admin-user> -p <password> -a <hostname> set flush_param access_scanner_enabled false

• Mike

[ota]

Dear mreiche

Thank you very much for the useful information.
I understand that upgrading to 7.x may improve operation.
I also understand that the log is output by the access scanner, and the procedure for disabling it.

I apologize for asking a second question about the option you provided, but
what effect does disabling this access scanner have?
I looked into the access scanner and found that it is used to determine which documents to load during warmup,
but I don’t know how it affects the operation, failover, and rebalancing, so I’m not sure whether it’s OK to apply it to the environment I’m currently using.
If there is any documentation that provides more details about the access scanner, I would appreciate it if you could let me know.

Since it may not be conveyed by machine translation, I will also post the original text.

—Start
mreiche様

有益な情報、誠にありがとうございます。
7.xにバージョンアップすることで動作が改善される可能性がある旨、承知しました。
また、アクセススキャナが出力されるログであり、そちらを無効にする手順についても把握出来ました。

頂いたオプションについて重ねて質問をしてしまい申し訳ないのですが、
このアクセススキャナーを無効化するとどのような影響がございますでしょうか。
アクセススキャナーについて調べてみましたが、「ウォームアップ時にどのドキュメントを読み込むかの判断に使用する」という内容を見つけましたが、
稼働中・フェイルオーバー・リバランス時にそれぞれどう影響が出るのか解りかねており、運用中の環境に適用して良いか判断しかねる状況です。
もしアクセススキャナーについての詳細が分かるドキュメントがございましたら、ご案内頂けますと幸いです。
—End

[mreiche]

You can safely disable it without affecting failover or rebalancing. It is just for tracking access to liad documents on startup.

[ota]

Dear mreiche

Thank you very much for your prompt response.

I understand that the access scanner can be safely disabled.
This will resolve the issue.

Thank you very much for your time despite your busy schedule.
Kind Regards,