Mysql – Cannot create stored procedure

Since you are connecting through a SSH tunnel, this means that the MySQL port 3306 from us-east-1.amazonaws.com is being opened locally on your computer. The ip address of your computer is 127.0.0.1 or localhost. When you connect to the mysql server on us-east-1.amazonaws.com, you're actually accessing it via 127.0.0.1, i.e. your computer. If you had another tunnel open, or MySQL running locally on your computer, then it may be that other MySQL server that's rejecting your authentication attempts

There are some tests you can try :

1. What ports is you Windows computer listening on

From a command prompt : netstat -a (lists all the ports that are open)

In linux it would be : netstat -tlpn

2. Basic connectivity test

From a DOS command prompt or linux console : telnet 127.0.0.1 3306

If you get a time out, or some other program responds then your tunnel isn't setup correctly.

3. Change the port number that MySQL Workbench is opening locally

We're assuming that MySQL workbench is creating the tunnel on your computer. If so, in MySQL workbench, try tunneling through another port number like 9000.

Make sure that 9000 wasn't listed as an open port from : netstat -a

If you have ssh access to us-east-1.amazonaws.com

4. Try connecting to MySQL from us-east-1.amazonaws.com

mysql -u myuser -h 127.0.0.1 -p

And as Rolando said, you'll want to verify that you are connecting with the right credentials. For example, if you are connecting as myuser@127.0.0.1 and you have a user myuser without a host, you probably won't be able to connect using user@127.0.0.1.

An answer:

After looking into this further, I determined that the call:

UPDATE mytable SET Flag = 0 where Id = 10

was being called also in a stored procedure which took a parameter of type BIT and did something like so:

UPDATE mytable SET Flag = theFlagValue where Id = theId;

While this worked fine on the master - the mytable would be updated with the correct flag value for any rows matching the Id - it wouldn't work on the slave.

My thought on this is that it involves how the data is serialized when sent to the slave. That type mismatch was fine on the master but not on the slave.

I was able to modify that stored procedure to take a TINYINT instead and it works flawlessly now.