Centos 6.X

got the same error, on a server stand alone

due to my.cnf

collation was specified in my.cnf
[mysqld]
collation_server = utf8_unicode_ci

cluster control set this options by default, I replace it by general_ci and all work fine

Before I close it as a configuration issue, I want to get a consult from bar, because I find the behavior rather confusing.
It has nothing to do with Spider, the problem boils down to the following:

# Server should be started with 

# --collation-server=utf8_unicode_ci --character-set-server=utf8

drop procedure if exists p1;

# This works

select count(*) from INFORMATION_SCHEMA.COLUMNS

  where COLUMN_NAME = 'server';

create procedure p1 (c char(255))

  select count(*) from INFORMATION_SCHEMA.COLUMNS

    where COLUMN_NAME = c;

# But this does not

call p1('server');

So, when the server is started with such charset/collation, the comparison of the I_S column to a literal works okay as a plain SQL, but inside a procedure it fails. It's the same on earlier versions, both MariaDB and MySQL, but I'm not sure it's supposed to be so.

it's strange :

--collation-server=utf8_unicode_ci !
because it failed with that and worked with general_ci

Stored routine variables and parameters use the database character set and collation by default.
To avoid this error, one should use explicit CHARACTER SET and COLLATE clauses at CREATE PROCEDURE time, e.g.:

create procedure p1 (c char(255) character set utf8 collate utf8_general_ci)

  select count(*) from INFORMATION_SCHEMA.COLUMNS

    where COLUMN_NAME = c;

Another option is to use explicit COLLATE in SELECT, e.g.:

create procedure p1 (c char(255))

  select count(*) from INFORMATION_SCHEMA.COLUMNS

    where COLUMN_NAME COLLATE utf8_general_ci = c;

install_spider.sql should be fixed using either of the ways.

Closing because 10.1 was EOL and spider is no longer initialised using the install_spider.sql script