Problem with the synchronization of the web interface and the database

[Cristian Ancines]

Hello everyone,

I am writing because we have a problem with the synchronization of the web interface and the database, to describe the problem nothing better than an example:

When changing a value in the database, from the parameters tab, (FIREWALL_CHECKER_RESULT)



the change is not applied.



It is necessary to restart the database service



to take the change.



That implies that our system is down for a few minutes, a situation that we don't like.

Any ideas that can guide us to the solution?

Thank you very much community and regards.

 

[cobaltit]

You made change that requires a restart of the services to take effect. Much like sometimes when you install software on a Windows PC you need to restart. It seems things are working as expected. What's the problem?

 

[Cristian Ancines]

Thanks for your response,

We have created several 3CX servers in the Linux operating system, among them (50) there are two 3CX servers that present the problem described.

On all other 3CX servers synchronization works immediately.

 

[JohnS_3CX]

Hi Cristian,

Beyond the simple example above, what practical problems is this causing you with the normal operation of those instances?

 

[Cristian Ancines]

We mainly use it when updating to a higher version (15.5 to 16).

The person who schedules the updates makes two changes to the system (BD) so that the technician who executes the update is forced to perform the requested checks when observing the dashboard.

one is the revision of the firewall to correct the network problems before the update,

and the other is to make a synchronization with the client's audios (they are not included in the backup for speed and storage space) creating the attribute "RECS_SYNC_REQUIRED = 1".

 

[JohnS_3CX]

Hi Cristian,

These parameters are not expected to immediately reflect when you change them manually, they are not meant to function that way in the first place. They are part of a series of events that gets triggered. For example Firewall checker stops services before running so when it has done its job and has updated the value the interface shows the correct indicator as we meant it to function.

The second value for recordings is also adjusted during an upgrade only, so it is not really meant to be changed manually and again services are restarted during a series of events that takes place during the procedure.

In short, for these specific things we would not really classify it as an issue unless it affects the designed functionality of the system.

Notes:

RECS_SYNC_REQUIRED is something we automatically take care of when updating from 15.5 to 16 so that should not be necessary to carry out. It only needs to run once under normal conditions.

The firewall check can also be triggered by deleting FIREWALL_CHECKER_RESULT parameter as this is not originally there when installing a new system. It is generated at the first check.

 

[Cristian Ancines]

Thank you for your response, my English is not good, I ask for your patience with my answers.

The situation that causes me doubts is:

Why there are two different ways of operating on the servers 3CX?.

If I compare two Linux servers that have been installed in the same way and with the same sources, when modifying the database values they behave differently?

One updates them immediately and the other does not.

Thanks for all your guidance.

 

[JohnS_3CX]

Hi Cristian,

No problem, we are here to help.

The reason is that sometimes values will be cached until the service decides it's time to recheck them or until you force it by restarting it.