请问一下WAL文件和write-buffer-size参数关系

[AVOlili]

write-buffer-size设置为256M时,WAL文件大小会快速涨到280M左右；write-buffer-size设置为64M时，wal文件只会涨到70几M。但是我的理解应该是wal size > db-write-buffer-size而不应该是write-buffer-size相关,能方便解答下吗?


下面这个是参考网上得到的部分rocksdb信息

[LIBA-S]

WAL文件本质是redo log的，一旦相关的内存信息（write buffer内容）持久化到磁盘（sst文件），那这部分log就可以安全删除了。所以和cf的write buffer size相关。

[AVOlili]

有关系，但是想知道是什么关系，我记得刘振说过每个slot 5种数据结构会使用10个memtable(rocksdb中一个列簇使用一个。set hash list 使用2个列簇。zset使用3个)。那么每种数据结构的总的memtable大小应该不一样呀，但是结果是每种数据结构的WAL都差不多大

[LIBA-S]

不严格的来讲，可以粗略认为db_write_buffer_size是WAL的上限，write_buffer_size为下限（在未手动设置max_wal_size和flush cf的前提下）。大多数情况下，每个cf的数据量和负载是不一样的，所以同时写满的概率极低。拿咱们的list来说，一个为meta cf，一个为data cf，显然data cf的数据量和负载更大，更容易写满（触发flush，切换WAL）。

[AVOlili]

不严格的来讲，可以粗略认为db_write_buffer_size是WAL的上限，write_buffet_size为下限（在未手动设置max_wal_size和flush cf的前提下）。大多数情况下，每个cf的数据量和负载是不一样的，所以同时写满的概率极低。拿咱们的list来说，一个为meta cf，一个为data cf，显然data cf的数据量和负载更大，更容易写满（触发flush，切换WAL）。

好的，谢谢

[mzygQAQ]

不严格的来讲，可以粗略认为db_write_buffer_size是WAL的上限，write_buffer_size为下限（在未手动设置max_wal_size和flush cf的前提下）。大多数情况下，每个cf的数据量和负载是不一样的，所以同时写满的概率极低。拿咱们的list来说，一个为meta cf，一个为data cf，显然data cf的数据量和负载更大，更容易写满（触发flush，切换WAL）。

您好 想咨询下 我看rocksdb每个cf是有独立的memtable， 但是多个cf共用wal 还是以lists为例，dataCF和metaCF 共用wal, 这种情况下 dataCF应该很容易触发memtable-flush的 但是metaCF却不一定， 这会不会因为MetaCF改动小很久才flush 导致wal迟迟无法删除。 我理解是必须dataCF的memtable和metaCF的memtable都flush了 相关的wal才能被删除的

[yapple]

max_total_wal_size 于2021年11月25日 (周四) 12:02 ***@***.***> 写道: 不严格的来讲，可以粗略认为db_write_buffer_size是WAL的上限，write_buffer_size为下限（在未手动设置max_wal_size和flush cf的前提下）。大多数情况下，每个cf的数据量和负载是不一样的，所以同时写满的概率极低。拿咱们的list来说，一个为meta cf，一个为data cf，显然data cf的数据量和负载更大，更容易写满（触发flush，切换WAL）。 您好 想咨询下 我看rocksdb每个cf是有独立的memtable， 但是多个cf共用wal 还是以lists为例，dataCF和metaCF 共用wal, 这种情况下 dataCF应该很容易触发memtable-flush的 但是metaCF却不一定， 这会不会因为MetaCF改动小很久才flush 导致wal迟迟无法删除。 我理解是必须dataCF的memtable和metaCF的memtable都flush了 相关的wal才能被删除的 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#980 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOIBJAHJVJCCEZIIEFWTVDUNWYMHANCNFSM4TMO2SJQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.