This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
wiki:qclug_meeting_minutes_2-7-2017 [2017/02/08 02:17] Aaron Johnson |
wiki:qclug_meeting_minutes_2-7-2017 [2017/02/08 02:48] Aaron Johnson |
||
---|---|---|---|
Line 28: | Line 28: | ||
side converstation: | side converstation: | ||
- tom was reminiscing of when there were internet yellow pages types books | - 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: | topic presentation notes: | ||
- the actual galera presentation began at exactly 7:19PM (central) | - the actual galera presentation began at exactly 7:19PM (central) | ||
Line 53: | Line 54: | ||
- corosync supports either multicast or unicast in a configuration called a ring | - corosync supports either multicast or unicast in a configuration called a ring | ||
- it supports resource agents and fencing agents | - it supports resource agents and fencing agents | ||
- | - fencing agents are available via prepackaged scripts | + | - fencing agents are available via prepackaged scripts (to hardware kill a misbehaving node) |
- | - cross conversation was had talking about openstack (which uses mysql galera and pacemaker as well) and we found that travis's demo cluster was very similar to how openstack works. | + | - 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... |
- | - 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. | + | - 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. |
</code> | </code> |