> hopefully you did run mysql_upgrade first on the slave as all docs in that > context saying and after that on the master
Cool!! Yeah, running mysql_upgrade did the trick. After I performed that on the slave, that error went away. I actually did the same on both nodes figuring it would be best to keep both nodes identical. Sorry, I'm a little new to database administration. Been working mostly on the SA side for years now however. 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 What I'm doing is using a dump from last night's backup on both nodes. Once I get replication working the way I want I'm going to do another final dump from the live web node. And then stop replication and import that backup into both nodes. Then start it up again and point the web nodes to the new HA/Mariadb setup that I'm working on. We've been having some availability problems with the database lately on this wiki site. The site runs on 3 t2 micros and the database lives on one of the web nodes. And occasionally the database crashes because it's too squeezed for memory. I figure that moving mysql (or mariadb in this case) to another 2 nodes and going for high availability will solve that problem. So now that I have replication working fine going from db1 to db2 in master slave, I just reversed the replication direction of the replication so I can have master/master working. So now I have master / slave going from db1 -> db2 and just a minute ago I setup master / slave going from db2 -> db1. And if I'm not mistaken that's all that Master/Master is? Is there anything else I need to worry about really, in terms of achieving HA? Not sure if I'm oversimplifying this.... Thanks, Tim On Wed, Jul 22, 2015 at 10:38 AM, Reindl Harald <h.rei...@thelounge.net> wrote: > > > 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 > > > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
