QCLUG Wiki

February QCLUG Meeting

---
date: 2/7/2017
topic: mysql galera with pacemaker
notes: >
  opening comments:
    - the meeting opened 8.5 minutes late due to unknown reasons
    - we then decided to introduce ourselves (even though there we no new attendees...)
    - during introductions we decided to come up with new meeting topics
    - here are the meeting topic ideas
  ideas:
    travis: php
    chad: irc
    dan: phpmyadmin
    sunil: target a single school (augustana or kaplan)
    christian: gluster
    aaron: drbd (actually this was suggested by travis)
    tom: qclug business cards (aaron want's stickers)
    brad: no ideas for brad...
    nelson: ansible
  officer position changes:
    - pr officer was renamed to marketing director
    - mascot position was added
  website maintenance:
    - laptop sign-up sheet was removed from the meeting format
  side converstation:
    - tom was reminiscing of when there were internet yellow pages types books
    - openstack was brought up (which uses mysql galera and pacemaker as well) and we found that travis's demo cluster was very similar to how openstack works.
    - tom mentioned that there are db2 databases and clients that implement high availability in a similar way but the clients are actually 'smart' and can actually choose another db server when connection issues occur.
  topic presentation notes:
    - the actual galera presentation began at exactly 7:19PM (central)
    - the first slide (after title slide) started at 7:24PM
    - per tom's outrageous outburst we learned that mysql was forked to mariadb by facebook (is this true?)
    - according to travis a database is the same thing as referenced excel spreadsheets
    - travis proceeded to show a video( that actually was just an audio recording displaying a pixelated desktop) of a sql server interview..
    - the recorded interview was hilarious
    - galera supports synchronous replication, which means it has to commit writes to all replicas before the write is considered complete
    - this type of replication however is not designed to work well with databases that do large volume small entry database writes
    - travis says in general the way galera works is like voodoo
    - at approximately 7:36 sunil's phone rang interupting the entire meeting and disrupting everthing
    - tom suggested databases that implement 'sharding' might be better suited as a high available solution for certain types of databases
    - alex began making fun of tom's use of the word sharding not knowing that he actually misunderstood tom as he did not say the word 'sharting' (notice the t in the word) which would have been much funnier but also quite awkward considering the conversation context had nothing to do with accidental bowel movement.
    - at this point christian noticed that the mysql logo is of a dolphin and that the mariadb logo is of a seal
    - but then alex corrected everyone and explained that the mariadb logo is actually a 'sea lion' not a seal, which if you google 'sea lion vs seal' you will realize that alex is correct.
    - galera is compatible with both mariadb and mysql, but you get newer packages from mariadb
    - travis chose to go with mariadb
    - travis started his live demo at exactly 7:49
    - he decided to run his node-1 setup shell script before sharing the commands in the script, but this backfired because the live presentation god's frowned upon him and made his yum transaction for loading the mariadbs packages slower than dog shit.
    - worth noting, galera does not seem to offer a security mechanisim to prevent new galera nodes from joining the cluster (other than a configuration option for setting a unique cluster name)
    - tom wanted to know is galera is a name for a monster, we found that galera means "crowd" in portuguese
    - the presentation switched gears and travis started talking about pacemaker/corosync
    - corosync supports either multicast or unicast in a configuration called a ring
    - it supports resource agents and fencing agents
    - fencing agents are available via prepackaged scripts (to hardware kill a misbehaving node)
    - however no one knows why anyone would actually use a fencing agent since all of the clusters we've been involved in do not actually use fencing agents...
    - the presentation finished at 8:26 (on time) and the cluster was fully functional!
    - we tested galera's ability to run as a single cluster node after "ungraceful" shutdown and galera will not run properly without manual intervention so a 3 node cluster or use of the galera arbitrator is recommended for a 2 node cluster.