Integrating a new server into a well-established, but current, multiserver setup can present unique challenges, particularly when updating from older versions of ISPConfig 3, where certain database columns no longer exist in the current version. It is crucial to ensure that the latest version is installed. When installing the new system, you might encounter issues similar to what I experienced. For instance, the "web_domain" table previously included columns like "fastcgi_php_version" and "enable_spdy" in older versions of ISPConfig 3, but these columns are absent in the latest version. Additionally, errors often arise from the "sys_datalog" table, as the new server processes a potentially very old queue of tasks. The installation process typically proceeds without immediate issues; however, the web interface might not update, leading to unresolved jobs. The "ispconfig.log" might show errors such as: Code: 30.04.2024-13:10 - ERROR - Replication of datalog_id: 204 failed. Error: (web_domain) in MySQL server: (localhost) Unknown column 'fastcgi_php_version' in 'field list' 30.04.2024-13:10 - ERROR - Error in Replication, changes were not processed. 30.04.2024-13:10 - ERROR - Replication of datalog_id: 204 failed. Error: (web_domain) in MySQL server: (localhost) Unknown column 'enable_spdy' in 'field list' 30.04.2024-13:10 - ERROR - Error in Replication, changes were not processed. To resolve this issue, I manually added the missing columns to the new server's "web_domain" table. Opting for a simple solution, I created a varchar(20) column that allows null values. This workaround allowed the system to process jobs smoothly and subsequently reset the table to its original configuration. Perhaps a TODO for the developers?!
All servers in the setup need to be on the same version. If they are, their databases will have the same structure. The column 'enable_spdy' was dropped in version 3.2 for example.
The issue is that the datalog gets replayed for records with server_id = 0 to get the new node in sync with the other nodes. The removal of database fields can indeed cause issues. So we will have to find to get things in sync without replaying all the data, maybe a special option for Tools > resync might be a way plus set the updated column of the new node to the max datalog_id to prevent the data replay. This would also allow us to clean up server_id = 0 records in the datalog.
