Merge branch 'develop' into MAX-324

Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md

@@ -59,11 +59,16 @@ As with uuid, MaxScale must have a unique server-id for the connection it makes
 
 ### user
 
-This is the user name that MaxScale uses when it connects to the master. This user name must have the rights required for replication as with any other user that a slave uses for replication purposes.
+This is the user name that MaxScale uses when it connects to the master. This user name must have the rights required for replication as with any other user that a slave uses for replication purposes. If the user parameter is not given in the router options then the same user as is used to retrieve the credential information will be used for the replication connection, i.e. the user in the service entry.
+
+The user that is used for replication, either defined using the user= option in the router options or using the username and password defined of the service must be granted replication privileges on the database server.
+
+    MariaDB> CREATE USER 'repl'@'maxscalehost' IDENTIFIED by 'password';
+    MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'maxscalehost';
 
 ### password
 
-The password of the above user.
+The password of the above user. If the password is not explicitly given then the password in the service entry will be used. For compatibility with other username and password definitions within the MaxScale configuration file it is also possible to use the parameter passwd=.
 
 ### master-id
 
@@ -87,7 +92,7 @@ This defines the value of the heartbeat interval in seconds for the connection t
 
 ### burstsize
 
-This parameter is used to define the maximum amount of data that will be sent to a slave by MaxScale when that slave is lagging behind the master. In this situation the slave is said to be in "catchup mode", this parameter is designed to both prevent flooding of that slave and also to prevent threads within MaxScale spending disproportionate amounts of time with slaves that are lagging behind the master. The burst size can be defined in Kb, Mb or Gb by adding the qualifier K, M or G to the number given.
+This parameter is used to define the maximum amount of data that will be sent to a slave by MaxScale when that slave is lagging behind the master. In this situation the slave is said to be in "catchup mode", this parameter is designed to both prevent flooding of that slave and also to prevent threads within MaxScale spending disproportionate amounts of time with slaves that are lagging behind the master. The burst size can be defined in Kb, Mb or Gb by adding the qualifier K, M or G to the number given. The default value of burstsize is 1Mb and will be used if burstsize is not given in the router options.
 
 A complete example of a service entry for a binlog router service would be as follows.
 
@@ -100,6 +105,8 @@ A complete example of a service entry for a binlog router service would be as fo
     user=maxscale
     passwd=Mhu87p2D
 
+The minimum set of router options that must be given in the configuration are are server-id and aster-id, default values may be used for all other options.
+
 ## Listener Section
 
 As per any service in MaxScale a listener section is required to define the address, port and protocol that is used to listen for incoming connections. In this case those incoming connections will originate from the slave servers.

server/modules/routing/binlog/blr.c

@@ -270,6 +270,10 @@ unsigned char	*defuuid;
 				{
 					inst->password = strdup(value);
 				}
+				else if (strcmp(options[i], "passwd") == 0)
+				{
+					inst->password = strdup(value);
+				}
 				else if (strcmp(options[i], "master-id") == 0)
 				{
 					inst->masterid = atoi(value);
@@ -977,6 +981,24 @@ ROUTER_INSTANCE	*router = (ROUTER_INSTANCE *)instance;
 int		error, len;
 char		msg[85], *errmsg;
 
+	if (action == ERRACT_RESET)
+	{
+		backend_dcb->dcb_errhandle_called = false;
+		return;
+	}
+
+	/** Don't handle same error twice on same DCB */
+        if (backend_dcb->dcb_errhandle_called)
+	{
+		/** we optimistically assume that previous call succeed */
+		*succp = true;
+		return;
+	}
+	else
+	{
+		backend_dcb->dcb_errhandle_called = true;
+	}
+
 	len = sizeof(error);
 	if (router->master && getsockopt(router->master->fd, SOL_SOCKET, SO_ERROR, &error, &len) == 0 && error != 0)
 	{

server/modules/routing/binlog/blr_master.c

@@ -314,6 +314,7 @@ char	query[128];
 			"Invalid master state machine state (%d) for binlog router.",
 			router->master_state)));
 		gwbuf_consume(buf, gwbuf_length(buf));
+
 		spinlock_acquire(&router->lock);
 		if (router->reconnect_pending)
 		{
@@ -335,7 +336,20 @@ char	query[128];
 		return;
 	}
 
-	if (router->master_state != BLRM_BINLOGDUMP && MYSQL_RESPONSE_ERR(buf))
+	if (router->master_state == BLRM_GTIDMODE && MYSQL_RESPONSE_ERR(buf))
+	{
+		/*
+		 * If we get an error response to the GTID Mode then we
+		 * asusme the server does not support GTID modes and
+		 * continue. The error is saved and replayed to slaves if
+		 * they also request the GTID mode.
+		 */
+        	LOGIF(LE, (skygw_log_write(
+                           LOGFILE_ERROR,
+			"%s: Master server does not support GTID Mode.",
+				router->service->name)));
+	}
+	else if (router->master_state != BLRM_BINLOGDUMP && MYSQL_RESPONSE_ERR(buf))
 	{
         	LOGIF(LE, (skygw_log_write(
                            LOGFILE_ERROR,

server/modules/routing/binlog/blr_slave.c

@@ -706,7 +706,7 @@ int	len, actual_len, col_len, seqno, ncols, i;
 	strncpy((char *)ptr, column, col_len);		// Result string
 	ptr += col_len;
 
-	sprintf(column, "%d", router->service->databases->port);
+	sprintf(column, "%d", router->service->dbref->server->port);
 	col_len = strlen(column);
 	*ptr++ = col_len;					// Length of result string
 	strncpy((char *)ptr, column, col_len);		// Result string