moonming commented on issue #10500: URL: https://github.com/apache/apisix/issues/10500#issuecomment-1818315794
If the configuration of the control plane does not change, but etcd is compressed, the revision of etcd will not change. At this time, the APISIX data plane will not be configured synchronously, and the cache will not be cleared. However, if etcd compression and configuration updates are performed at the same time, and the APISIX data plane finds that a certain revision of etcd cannot be obtained, full synchronization will be triggered and the cache will be cleared: https://github.com/apache/apisix/blob/master/apisix/core/etcd.lua#L239-L245 To give an example: the etcd revision at 9 a.m. is 100. At 9:10, etcd starts to compress the data, and new changes are also written to etcd at the same time. The latest revision becomes 110. When the compression is completed, the data in revisions from 1 to 109 are gone. During this process, the APISIX data plane may obtain revision 105, but revision 105 in etcd has been compressed. Then APISIX will trigger full synchronization. This may be the problem you are encountering. The solution can be to not clear all historical revisions when performing etcd compression, but to retain some of the most recent revisions, such as the most recent 1,000. Foe example use `auto-compaction-retention = 1000` in etcd https://etcd.io/docs/v3.4/op-guide/maintenance/#auto-compaction You can try this solution. If you have any questions, you can update here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
