[MXS-70] Allow configuring modules dynamically without process restart Created: 2015-03-27  Updated: 2016-10-17  Resolved: 2016-10-17

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.1.0
Fix Version/s: N/A

Type: New Feature Priority: Major
Reporter: Dipti Joshi (Inactive) Assignee: markus makela
Resolution: Won't Do Votes: 2
Labels: dynamic_configuration

Issue Links:
Relates
relates to MXS-163 Reload config leaks memory Closed
relates to MXS-302 Allow maxscale startup configuration ... Closed
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
MXS-67 Mechanism to reload dbfwfilter rules Sub-Task Closed markus makela  
MXS-178 NamedServer, TopN filter, Tee-filter ... Sub-Task Closed markus makela  
MXS-320 Mention Unknown Filters in Error Log Sub-Task Closed markus makela  

 Description   

Today in order have a filter module or router module configuration to take into effect, a user have to

  • update MaxScale.cnf
    -restart maxscale

which means all the existing client and server connections get dropped.

In production environment this is not usable approach to have to restart MaxScale for every filter configuration change. A mechanism to dynamically change filter or any other module configuration without restarting maxscale is needed.

This came across when @Kolbe Kegel tried to change firewall filter rules and reload it.

Proposal is t that "each plugin has its own set of actions and information that should be exposed via an API. Some plugins might want to expose and implement a "reload" method so that their configuration can be reloaded."

Along with this corresponding maxadmin command should also be added.

 Comments   
Comment by markus makela [ 2015-05-01 ]

This would be the optimal place to do some module API modifications. The reloading of modules could be implemented by creating module unloading points to each interface. Adding module-specific function calls could be implemented by callback registration to a core MaxScale service.

Comment by Dipti Joshi (Inactive) [ 2015-05-13 ]

Massimiliano Pinto Please log work, so remaining estimate gets updated

Comment by Massimiliano Pinto (Inactive) [ 2015-05-14 ]

A new server is added to server lists in service but not in monitor

Comment by Massimiliano Pinto (Inactive) [ 2015-05-14 ]

A new server "server_33" added into MaxScale.cnf is not seen by show servers, after reload config

MaxScale> reload config
Reloading configuration from file.
MaxScale> show servers
Server 0x7f2864000a60 ((null))

we should see "server_33" instead

Resolved in 'develop' by adding server_set_unique_name()

Comment by Dipti Joshi (Inactive) [ 2015-05-20 ]

Massimiliano Pinto , Markus Makela Please log work, so remaining estimate gets updated

Comment by Dipti Joshi (Inactive) [ 2015-06-02 ]

markus makela, Here is the priority list of filters

(1) firewall, regex, qla
(2) tee-filter, topN, NamedServer

Routers:
RWSplit, Schema Router, ReadConnection Router

Monitor:
(1) MySQLMon, GaleraMon
-------------------------------------
Future:
MQ filter
Slave Lag
NDBMon, MMM

Comment by Dipti Joshi (Inactive) [ 2015-06-04 ]

markus makela Can we put link to test cases here ?

Comment by markus makela [ 2015-06-11 ]

test cases: https://docs.google.com/spreadsheets/d/1zTtk34nbhtLxSW6X4VjiSPk6673YJgNGjWCes1EOwuM/edit?usp=sharing

Comment by Timofey Turenko [ 2015-06-12 ]

(gdb) bt
#0 0x0000000000523831 in spinlock_acquire ()
#1 0x00007f8f8c9a3015 in newSession (instance=0x0, session=0x7f8f80000dc0) at /home/ec2-user/workspace/server/modules/routing/cli.c:201
#2 0x000000000052f5c3 in session_alloc ()
#3 0x00007f8f8c77da99 in maxscaled_accept (dcb=0x30b30f0) at /home/ec2-user/workspace/server/modules/protocol/maxscaled.c:294
#4 0x000000000053879b in process_pollq ()
#5 0x0000000000537e6e in poll_waitevents ()
#6 0x00007f8fb2836851 in start_thread () from /lib64/libpthread.so.0
#7 0x00007f8fb11a890d in clone () from /lib64/libc.so.6
(gdb)

It was slave_lag test, very first step:

11: Creating test table
11: sql_len=588921
11: server2: 0
11: Error: can't execute SQL-query: select @@server_id; – maxscale max_slave_replication_lag=20
11: MySQL server has gone away

Comment by Dipti Joshi (Inactive) [ 2015-06-17 ]

markus makela Is there any configuration changes that we need to document for this ?

Comment by Timofey Turenko [ 2015-06-18 ]

7 new crashes:
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/fwf/core-maxscale-11-498-498-8241-1434635790
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/bug681/core-maxscale-11-498-498-5244-1434623830
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/setup_binlog/core-maxscale-11-498-498-5639-1434624595
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/binlog_incompl/core-maxscale-6-498-498-8003-1434634758
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/bug654/core-maxscale-11-498-498-4796-1434623580
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/bug601/core-maxscale-11-498-498-2303-1434623378
http://jenkins.engskysql.com/test/LOGS/centos6.5_x86_64/BRANCH/MXS-70/20150618-16/slave_failover/core-maxscale-11-498-498-1719-1434618462

Comment by Timofey Turenko [ 2015-06-18 ]

passed/failed cases: http://jenkins.engskysql.com/CDash/viewTest.php?onlyfailed&buildid=77

Comment by Dipti Joshi (Inactive) [ 2015-08-10 ]

markus makela Can you share the documentation update links ?

Comment by markus makela [ 2015-09-01 ]

Here's a link to the updated documentation page: https://github.com/mariadb-corporation/MaxScale/blob/MXS-70/Documentation/Documentation-Contents.md

Comment by markus makela [ 2016-10-17 ]

This implementation of dynamic configuration reloading is not usable. Any future versions should filed under a new issue.

Generated at Thu Feb 08 03:56:33 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.