Config rewrite support

[boomballa]

Did you search GitHub Issues and GitHub Discussions First?

2511

Seeing that someone previously suggested support for the config rewrite command, but didn't elaborate on the reasoning, I'd like to give my own personal opinion.

Is your feature request related to a problem? Please describe. Recently, I've been organizing the scripts and data output related to dragonfly monitoring, and I've seen the official monitoring based on Prometheus and Grafana before, but I feel that the monitoring items are a bit less than enough to support the monitoring needs of the production environment, so I'd like to do more monitoring data extraction. This time there a places I want to propose, let's communicate together to see if there is a need to improve.

• Config rewrite command support The reason for proposing this command support is that in the use of the production environment, we may hot change the instance configuration, for example, maxmemory and maxclient values, after the modification, I want to persist to the configuration file need to how to deal with? At present, it seems that we can only manually modify the configuration file to achieve consistency between the instance configuration and the parameters configured in the instance configuration file, but manual operation will inevitably have the possibility of error, there is no excuse for this. Another point is that if the instance supports the config rewrite command to meet the instance configuration and configuration file consistency, then I think the subsequent configuration changes can be added to the automated operation and maintenance process, whether it is a script or a platform operation, the addition of this command will make this operation will make the operation of the stated operation has become a simple silky smooth. In addition, the instance configuration and configuration file inconsistency I feel there is a stability hazard, if the instance is from the library, only modified the instance config configuration, while the configuration file is not modified in the case of master-slave switching occurs, if the configuration is lower than the master library configuration, regardless of maxmemory or maxclient configuration, I feel that there is a possibility of production accidents. Other configurations are the same, not to mention ...

We will treat configuration inconsistency as a case to assist the DBA in targeting the management of cached instances. In this case, it is normally necessary to alert the DBA to warn them.

Additional context I'm sorry I'm here to raise requirements again, hahaha, these requirements are trying to usability and reliability after using our dragonfly on-line to the production environment, I hope dragonfly is getting better and better, looking forward to the reply, together to discuss. 😃

[romange]

@boomballa thanks for suggesting these features. Can you please open a "process_id" issue separately and copy paste there what you wrote here? These features require a different effort, so better to separate.

[boomballa]

@romange Okay, I'll take care of it right away.

[boomballa]

@romange Okay, I'll take care of it right away.

I've separated the two issues, tough.

[boomballa]

@romange Hi , I would like to ask, is this current requirement on hold because of low priority? I've been following it and I don't seem to see any progress, can this requirement be prioritized and supported by spending some time on it? I think this config rewrite function is still important for the stability of the cluster, otherwise some configurations may not be able to hot-load the instances need to be frequently switched and restarted, the use of online business is not very friendly.

[romange]

Hello @boomballa . yes, this issue has a low priority. We will welcome community driven contributions for this issue but we won't be able to work on it ourselves.

[boomballa]

Hello @boomballa . yes, this issue has a low priority. We will welcome community driven contributions for this issue but we won't be able to work on it ourselves.

Okay, got it.