Tuesday, November 11, 2014

Mariadb 10 Slave wont set up after upgrading from mariadb 5.5

We are in teh process of upgrading mariadb 5.5 databases to maridb 10. The actual upgrade process of the database has been flawless for the stand alone databases. I have started on our first replication set a pre-production system and after upgrading a slave to 10.1.14  have hit a wall

The maria10 database slave not starting up as a slave after upgrading from 5.5 The master is still running as 5.5

This is the error log

141111 10:57:10 [Note] Event Scheduler: Purging the queue. 0 events
141111 10:57:10 [Note] InnoDB: FTS optimize thread exiting.
141111 10:57:10 [Note] InnoDB: Starting shutdown...
141111 10:57:12 [Note] InnoDB: Shutdown completed; log sequence number 36086013855
141111 10:57:12 [Note] /usr/sbin/mysqld: Shutdown complete

141111 10:57:12 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld-nxq.pid ended
141111 10:57:13 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql/nxq
141111 10:57:13 [Note] InnoDB: Using mutexes to ref count buffer pool pages
141111 10:57:13 [Note] InnoDB: The InnoDB memory heap is disabled
141111 10:57:13 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
141111 10:57:13 [Note] InnoDB: Memory barrier is not used
141111 10:57:13 [Note] InnoDB: Compressed tables use zlib 1.2.3
141111 10:57:13 [Note] InnoDB: Using Linux native AIO
141111 10:57:13 [Note] InnoDB: Using CPU crc32 instructions
141111 10:57:13 [Note] InnoDB: Initializing buffer pool, size = 128.0M
141111 10:57:13 [Note] InnoDB: Completed initialization of buffer pool
141111 10:57:14 [Note] InnoDB: Highest supported file format is Barracuda.
141111 10:57:14 [Note] InnoDB: 128 rollback segment(s) are active.
141111 10:57:14 [Note] InnoDB: Waiting for purge to start
141111 10:57:14 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.20-68.0 started; log sequence number 36086013855
141111 10:57:14 [Note] Plugin 'FEEDBACK' is disabled.
141111 10:57:14 [ERROR] Failed to create a socket for IPv6 '::': errno: 97.
141111 10:57:14 [Note] Server socket created on IP: ''.
141111 10:57:14 [Note] Event Scheduler: Loaded 0 events
141111 10:57:14 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--log-basename=#' or '--relay-log=mysqld-nxq-relay-bin' to avoid this problem.
141111 10:57:14 [ERROR] Server id not set, will not start slave
141111 10:57:14 [ERROR] Failed to create slave threads
141111 10:57:14 [ERROR] Failed to allocate memory for the Master Info structure
141111 10:57:14 [Note] /usr/sbin/mysqld: ready for connections.

This is the server.cnf it isn't as clean and tidy as it should be but it is what it is


# this is only for the mysqld standalone daemon

binlog_format = mixed

# MASTER config
# log-bin=mysql-bin.log

# Autostart the event scheduler

# SLAVE config

# Performance Tuning

innodb_file_per_table = 1
innodb_flush_method = O_DSYNC


# this is only for embedded server

# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here

# This group is only read by MariaDB-10.0 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don't understand


I moved the server_ID value to the [mariadb-10.0] section from the [mysqld] section to try and find a solution

Update: Turns out the reason for this behaviour was due to a typo in the init.d startup script in this line defaultfile="/etc/my.cnf" It had to be changed from another location and it had an error. Funnily enough though the strace output was not helpful as it showed what appeared to be it reading the files in the /etc/my.cnf.d directory.

How did I find it? By using the startup process of executing mysqld --help. It displays the default location parameters and i could see the server-id set correctly

See ya round


No comments: