Am 22.07.2015 um 16:24 schrieb Tim Dunphy:
Hi Reindl,
what about running mysql_upgrade *directly* after the major update
and *before* touch anything else?
That was precisely what happened. In setting up the new database
machine, puppet had installed version 5 of mariadb. Before even starting
up version of for the first time, I uninstalled the RPM's for that
version and installed version 10.0.20 from the mariadb repo.
However I was able to solve this problem my recreating the keys and
certs. I had setup master/slave replication using this tutorial:
https://www.howtoforge.com/how-to-set-up-mysql-database-replication-with-ssl-encryption-on-centos-5.4
I'm not sure what the problem is with the way the keys are generated in
this article that could have caused that last, rather long email. :)
So after I regenerated the keys and certs using this method:
182 openssl genrsa -des3 -out db1.example.com.key 4096
183 openssl rsa -in db1.example.com.key -out db1.example.com.key
184 openssl req -new -key db1.example.com.key -out db1.jokefire.com.csr
185 openssl x509 -req -days 3650 -in db1.example.com.csr -CA ca.crt
-CAkey ca.key -set_serial 01 -out db1.example.com.crt
you need the same certs and same CA on both sides
*Last_Error: Unable to load replication GTID slave state from
mysql.gtid_slave_pos: Table 'mysql.gtid_slave_pos' doesn't exist*
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1146
* Last_SQL_Error: Unable to load replication GTID slave state from
mysql.gtid_slave_pos: Table 'mysql.gtid_slave_pos' doesn't exist*
Any idea what that error means and how I can get rid of it?
hopefully you did run mysql_upgrade first on the slave as all docs in that context saying and after that on the master
however, i would just double-rsync (hot and than cold) the whole datadir to the not running slave and just start replication with that binary identical copies from scratch, doing that in case of any replication issues for many years now and if it's just for safety
signature.asc
Description: OpenPGP digital signature
