You seem to be missing the monitor_interval paremeter. Setting it to a value of 1000 should be a good starting point. I will add the missing log messages in case of the missing parameter.
If this doesn't solve your problem, you can try enabling the trace log for more information. You can enable it by adding log_trace=1 under the [maxscale] section.
Thanks for your help 
Addind monitor_interval did not help.
Activated trace log but it seems there is no info about the problem:
MariaDB Corporation MaxScale /dev/shm/maxscale.13702/skygw_trace1.log Wed Apr 22 20:05:43 2015
|
-----------------------------------------------------------------------
|
--- Logging is disabled.
|
2015-04-22 20:05:43 --- Logging is enabled --
|
2015-04-22 20:05:43 Notification service feedback is not enabled
|
2015-04-22 20:05:43 Started session [1] for RW Split Service service
|
2015-04-22 20:05:43 Started session [2] for RW Split Service service
|
2015-04-22 20:05:43 Initialise MaxScaled Protocol module.
|
2015-04-22 20:05:43 Started session [3] for CLI service
|
The mysqlmon sends a SHOW SLAVE STATUS to all servers. If Slave_IO_Running and Slave_SQL_Running are both Yes, then the server is seen as a slave. After slaves are found, the master is found by building a replication tree based on the server_id of each server. The monitor tries to find the master by locating the node with the lowest depth i.e. the "root master" of the tree.
At this point, if the replication is OK but the slave_IO is not running on the slave, the master can't be found because the replication is not active. MaxScale sees this as broken replication and will set the states of the servers to Running but not Master/Slave.
If you can confirm that Slave_IO is running and the Master_Server_id is the server id of the master from the output of a SHOW SLAVE STATUS to the slave, it would confirm that the replication is in working order. Otherwise your configuration seems to be correct. Since the error and trace logs are empty, I would imagine that MaxScale is not considering this an erroneous state of MaxScale but broken replication.
This is the output of "mysql -e 'SHOW SLAVE STATUS\G'":
*************************** 1. row ***************************
|
Slave_IO_State: Waiting for master to send event
|
Master_Host: db1.local
|
Master_User: repli
|
Master_Port: 3306
|
Connect_Retry: 60
|
Master_Log_File: mariadb-bin.000016
|
Read_Master_Log_Pos: 15211864
|
Relay_Log_File: relay-bin.000034
|
Relay_Log_Pos: 15212153
|
Relay_Master_Log_File: mariadb-bin.000016
|
Slave_IO_Running: Yes
|
Slave_SQL_Running: Yes
|
Replicate_Do_DB:
|
Replicate_Ignore_DB:
|
Replicate_Do_Table:
|
Replicate_Ignore_Table:
|
Replicate_Wild_Do_Table:
|
Replicate_Wild_Ignore_Table:
|
Last_Errno: 0
|
Last_Error:
|
Skip_Counter: 0
|
Exec_Master_Log_Pos: 15211864
|
Relay_Log_Space: 15212489
|
Until_Condition: None
|
Until_Log_File:
|
Until_Log_Pos: 0
|
Master_SSL_Allowed: No
|
Master_SSL_CA_File:
|
Master_SSL_CA_Path:
|
Master_SSL_Cert:
|
Master_SSL_Cipher:
|
Master_SSL_Key:
|
Seconds_Behind_Master: 0
|
Master_SSL_Verify_Server_Cert: No
|
Last_IO_Errno: 0
|
Last_IO_Error:
|
Last_SQL_Errno: 0
|
Last_SQL_Error:
|
Replicate_Ignore_Server_Ids:
|
Master_Server_Id: 1
|
Master_SSL_Crl:
|
Master_SSL_Crlpath:
|
Using_Gtid: No
|
Gtid_IO_Pos:
|
As you can see, replikation is working and Master Server id is 1.
Does the 'maxscale' user have enough permissions? The monitor user needs the grants to execute the SHOW SLAVE STATUS to be able to resolve the replication tree.
Sorry for de delayed answer. I was on vacation.
Giving replication rights t other user solved the problem
Imho the documentation should be updated.
Question: What happens when master or slave dies?
Is there already any kind of failover implemented?
Thanks for your help again.
No problem, I'm glad this was resolved.
If an external mechanism is used to change the master to a new one MaxScale will notice it if the new master is in configuration file.
The documentation does have this information but it is in the Configuration Guide: https://github.com/mariadb-corporation/MaxScale/blob/master/Documentation/Getting-Started/Configuration-Guide.md#user
This was due to the maxscale user lacking privileges.