Zero to DBA Track at SELF

MySQL is proud to sponsor the Zero to DBA Track at the Southeast Linuxfest next June 11th-14th! Hotel rooms at the conference rate are going very quickly.

So what do you learn at the Zero to DBA sessions? There are two days of presentations from the MySQL and Postgresql communities. The goal of this track was to take novices and turn them into DBAs or at least give novices a good ‘leg up’ in the world. This is a friendly crowd with lots of other non-database sessions and many great non-tech social functions.

Friday
The Proper Care and
Feeding of MySQL for the
Busy Linux Admin
Dave Stokes

The MySQL Ecosystem
Colin Charles

Binary Log Management
Made Easy With MySQL
Utilities
Charles Bell

Scaling MariaDB and MySQL
Max Mether

To Shard or Not To Shard
Peter Zaitsev

Nulls Make Things Easier?
Bruce Momjian

MariaDB/MySQL Security
Essentials
Colin Charles

Saturday

Common Table Expressions
Richard Hipp

Practical MySQL
Performance Optimization
Peter Zaitsev

MySQL Workbench
Dave Stokes

MySQL Central @ Oracle Open World CFP Closes April 29th!

The Call for papers for MySQL Central @ Oracle Open World closes in just over a week! Now is the time to put together those ideas for a presentation you have had into shape before the last minute rush. The conference starts October 25th but the CFP closes April 29th! But we want you at this conference to present your best material.

So what if you have never submitted a talk in the past to any conference OR have not manged to get accepted for MySQL Central before? Get your best technical material together and write down the topic, 3-5 bullet points, and a conclusion. Then put your title, bullet points, and conclusion into a paragraph. That paragraph needs to fit into one of the six MySQL Central @ OpenWorld tracks:

  • Performance & Scalability
  • High Availability
  • NoSQL & Big Data
  • Cloud and DevOps
  • Database Administration
  • Architecture and Application Development

Submit your talk today here!

For an example, lets pretend your name is Montgomery Scott and you are a chief engineer. You have spent the last few months studying storing data from your transporter in BLOB under various storage engines. The title would obvious be Storing Transporter Data Efficiently with Various Storage Engines. Your main points are 1) It is easy to store transporter data in MySQL, 2) Blobs are used to store data because it is amorphous, 3) You would like to save the data in JSON for better investigation of the information, 4) Use InnoDB for crash recovery and row level locking as MyIsam proved too fragile and had crash recovery issues, and 5) Black Hole storage engine is fine for Tribbles. Your conclusion would be It is easy to store transporter data in MySQL given that you take the proper precautions.

Now smooth that into a paragraph. Get someone with some writing skill or marketing background to help smooth the flow of the sentences.

Storing Transporter Data Efficiently with Various Storage Engines
Data from teleportation transporters is often tricky to store. MySQL can provide fast and efficient storage of transporter data sets. Currently we use blobs due to the amorphous nature of the data but JSON is considered to provide better management and searching of the data. Initial MyIsam usage proved problematic and other storage engines have been successfully used. InnoDB’s features provide better crash recovery for this critical data and simultaneous lookup of data. Use of the Black Hole storage engine has proven to be the best performing for small furry data sets should not be used for no ephemeral information. This session will cover our best practices that we discovered for storing transporter data.

So Scotty can bean up, er, post paper today.

MySQL Fabric – Faulty to Secondary

MySQL Fabric is a great tool for managing a farm of MySQL servers. In the last two posts you can see how High Availability Fail over and Sharding work. When things are working right, the group lookup_servers will look something like this:
server_uuid address status mode weight
------------------------------------ ----------- --------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 PRIMARY READ_WRITE 1.0

This is a three node farm with a PRIMARY for READ-WRITE operations and two SECONDARY servers for READ_ONLY.

But that about the times when one of the servers is not doing do great and shows up as FAULTY on a group lookup_servers or group health report?

uuid is_alive status is_not_running is_not_configured io_not_running sql_not_running io_error sql_error
------------------------------------ -------- --------- -------------- ----------------- -------------- --------------- -------- ---------
09d13be1-cdd0-11e4-8643-0800273b9c80 1 FAULTY 0 0 0 0 False False
0f611996-cdd0-11e4-8643-0800273b9c80 1 SECONDARY 0 0 0 0 False False
11aae7e7-cdd0-11e4-8643-0800273b9c80 1 PRIMARY 0 0 0 0 False False

Possible values for status are FAULTY, SPARE, SECONDARY, PRIMARY, or CONFIGURING. So how is good old server ’09d13be1-cdd0-11e4-8643-0800273b9c80′ changed from FAULTY to SECONDARY?

The path is not as simple as just setting the status to to SECONDARY. First the server must be marked SPARE with mysqlfabric server set_status 09d13be1-cdd0-11e4-8643-0800273b9c80 spare. Use group lookup_servers to note the change of ’09d13be1-cdd0-11e4-8643-0800273b9c80′ to SPARE.

server_uuid address status mode weight
------------------------------------ ----------- --------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SPARE OFFLINE 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 PRIMARY READ_WRITE 1.0

Nut now the mode is OFFLINE. Now the status can be changed to SECONDARY.
mysqlfabric server set_status 09d13be1-cdd0-11e4-8643-0800273b9c80 secondary

And good old ’09d13be1-cdd0-11e4-8643-0800273b9c80′ is back as a happy, productive member of the farm.

Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- --------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 PRIMARY READ_WRITE 1.0

MySQL Fabric and Sharding

Last time we set up a High Availability server farm with MySQL Fabric. Now it is time to set up sharding. I will be using the good old World database and sharding the City table on the ID field. There are 4,079 cities in this table and they will be split in two. So one shard, that we will call CityLow will have the records 2,000 and below and the other records at 2,001 and above will be called CityHigh. We also need a global group for setting up sharding that will be called CityGlobal.

Sadly, the first step is to remove the previous setup with mysqlfabric manage teardown. This will remove the fabric database from the Fabric controller. Fabric itself has to be stopped with mysqlfabric manage stop. The command mysqlfabric manage setup will set up a fresh, clean fabric database. And then we can start the Fabric controller with mysqlfabric manage start --daemonize.

Now we crate the groups for CityLow, CityHigh, and CityGlobal.

mysqlfabric group create CityLow
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid finished success result
------------------------------------ -------- ------- ------
a7cafabf-1550-4f7c-a8e7-79458e47b9d5 1 1 1

state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1428436552.17 Triggered by .
4 2 1428436552.2 Executing action (_create_group).
5 2 1428436552.26 Executed action (_create_group).

mysqlfabric group create CityHigh
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid finished success result
------------------------------------ -------- ------- ------
81a92aa2-1c71-4327-9fc5-4e8098ebff5c 1 1 1

state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1428436556.61 Triggered by .
4 2 1428436556.64 Executing action (_create_group).
5 2 1428436556.7 Executed action (_create_group).

mysqlfabric group create CityGlobal
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid finished success result
------------------------------------ -------- ------- ------
ee83da52-fae2-4355-95b3-1ac58039c8d7 1 1 1

state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1428436562.23 Triggered by .
4 2 1428436562.26 Executing action (_create_group).
5 2 1428436562.32 Executed action (_create_group).

Servers are added with mysqlfabric group add CityLow 10.10.13.10, myslfabric group add CityHigh 10.10.13.20, and mysqlfabric group add CityGLobal 10.10.13.30. Then we promote a sever in each group with mysqlfabric group promote CityLow, mysqlfabric group promote CityHigh, and lastly mysqlfabric group promote CityGlobal.

A unique sharding ID is needed and I missed noting this unique number as I did not see it (here the docs are not matching the output of the commands). And this gave me problems with the step following this one.
mysqlfabric sharding create_definition range CityClobal
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

AttributeError: ‘NoneType’ object has no attribute ‘master’
I ignored the above error and carried on hoping all was well.

And I ran smack into a problem trying tell Fabric which table to use. mysqlfabric sharding add table_table 1 City.World ID The error message I recevied was DatabaseError: Command (INSERT INTO shard_tables(shard_mapping_id, table_name, column_name, range_check) VALUES(%s, %s, %s, %s), (‘1′, ‘World.City’, ‘ID’, False)) failed accessing (localhost:3306). 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`fabric`.`shard_tables`, CONSTRAINT `fk_shard_mapping_id` FOREIGN KEY (`shard_mapping_id`) REFERENCES `shard_maps` (`shard_mapping_id`)).!! I had seen ‘1’ in the docs but that was not working for me. So I peeked in the fabric.shard_maps table and found the magic number ‘2’.

mysqlfabric sharding add_table 2 World.City ID
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid finished success result
------------------------------------ -------- ------- ------
ab98c0a6-390d-4334-992e-557fc37b7a2d 1 1 1

state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1428437358.46 Triggered by .
4 2 1428437358.49 Executing action (_add_shard_mapping).
5 2 1428437358.56 Executed action (_add_shard_mapping).

Now tell Fabric how slice and dice the table into shards. Remember we want two — Low with 0-2000, and High with the rest.
mysqlfabric add_shard 2 CityLow/0,CityHigh/2000 --state=ENABLED
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid finished success result
------------------------------------ -------- ------- ------
f20da46d-6cc1-4464-a0dd-991b35d83e97 1 1 1

state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1428437428.99 Triggered by .
4 2 1428437429.03 Executing action (_add_shard).
5 2 1428437429.3 Executed action (_add_shard).
3 2 1428437429.22 Triggered by .
4 2 1428437429.3 Executing action (_add_shard_range_check).
5 2 1428437429.42 Executed action

So now we check to see which shard hold the record with the ID of 15 and it should be the CityLow shard on 10.10.13.10!
$mysqlfabric sharding lookup_servers World.City 15
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- ------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 PRIMARY READ_WRITE 1.0

And is ID 3333 on the CityHigh shard?

$mysqlfabric sharding lookup_servers World.City 3333
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- ------- ---------- ------
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 PRIMARY READ_WRITE 1.0

Yes!

The table is sharded! Next blog will cover some sharding magic.

MySQL Fabric : Testing High Availability Fail Over

Tine to test MySQL Fabric’s High Availability fail over. Last entry I set up a three node Fabric HA farm. This time I am going to ‘pull the plug’ on the servers in the farm and see if Fabric will sense the loss of the server and gracefully keep working.

To sum up the setup, I am using a laptop as the Fabric Controller and three virtual servers for the farm. The virtual servers are Vagrant instances

Example of Fabric environment tested
MySQL Fabric HA Diagram — Nice illustration of tested environment
creatively named db1 at 10.10.13.10, db2 at 10.10.13.20, and db3 at 10.10.13.30. All the MySQL instances are 5.6.23 and the MySQL Utilities are 1.6.1-alpha. See the last blog entry for details.

The MySQL Fabric HA farm has been started.
mysqlfabric group lookup_servers myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- --------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 PRIMARY READ_WRITE 1.0

Number ’30 is the PRIMARY node. A simple test program’s connector queries the farm and is actually talking to ’30. So time to issue vagrant down db3 to power off that server.

With db3 shut down, the test program now is communicating with ’20. So far, so very good.

mysqlfabric group lookup_servers myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- --------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 PRIMARY READ_WRITE 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 FAULTY READ_WRITE 1.0

MySQL Fabric has gracefully promoted ’20 from SECONDARY to PRIMARY. Time to bring down ’20!

mysqlfabric group lookup_servers myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- ------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 PRIMARY READ_WRITE 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 FAULTY READ_WRITE 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 FAULTY READ_WRITE 1.0

And the test program is chatting with ’10.

MySQL Fabric gracefully handles the failure of two out of the three nodes in the High Availability farm.

And for the pedantic, shutting off the last server in the farm will generate a ‘Connection with Fabric failed’ message.

MySQL Fabric — Setup new High Availability Group and USE it

Back to MySQL Fabric! Travel, conferences, and other work have kept me away for too long. So lets start by setting up a new High Availability MySQL Fabric farm and query it for some data. I started with a new install to make sure I was getting everything covered so that one day I will wrap all this up in a comprehensive ‘cookbook’ style article so that anyone can go from Zero to Fabric Hero.

So the first step was to set up my test system with a fresh install of Ubuntu 14.04. Next was the setup of three ‘guest’ Unbuntu 14.04 virtual servers with Vagrant that will comprise the actual HA farm. Next came the installation of MySQL 5.6.23 from the MySQL Apt Repository on the Fabric Controller and the virtual servers. Next comes the installation of the MySQL Utilities on the Fabric Controller system along with the Python Connector. And this time I went with the MySQL Utilities 1.6.1-alpha to get the latest and greatest version of the Fabric software and the Utilities. Both the Fabric and Utilities team have been very busy working the coding magic and it shows.

Next comes setting up Replication between three guest servers. I set up the account for replication and the grants but did not start replication. I installed the good ol’ World database on the first of the virtual servers and then used mysqldbcopy to copy the database over to the other two virtual servers in a quick fashion. Now the replication farm was complete and it was time to get back to the Fabric controller system.

Editing the /etc/mysql/fabric.cfg file, I put in a handy password where indicated. Then came the moment of truth — setting up Fabric and getting it running.

On the system that will be the Fabric Controller run the following:

fabric manage setup
[INFO] 1427317836.840587 - MainThread - Initializing persister: user (fabric), server (localhost:3306), database (fabric).
[INFO] 1427317846.353911 - MainThread - Initial password for admin/mysql set
Password set for admin/mysql from configuration file.
[INFO] 1427317846.388624 - MainThread - Password set for admin/mysql from configuration file.
[INFO] 1427317846.389658 - MainThread - Initial password for admin/xmlrpc set
Password set for admin/xmlrpc from configuration file.
[INFO] 1427317846.430082 - MainThread - Password set for admin/xmlrpc from configuration file.

The 1.6.1-alpha code has a new documentation page 8.2.3.1. Create the Associated MySQL Users for setting up various Fabric users. There are now accounts for Backing Store, Server User, Backup User, and Restore User and the recommended grants for each. Here I found a glitch as later on I had complaints that various users, created as per the docs, did not have all the permissions they needed. So I took a not-recommended-for-production-or-sanity shot cut and did a GRANT ALL on the account.

The fabric manage setup command creates a database named fabric. Currently there are nineteen tables in the database. I will have to blog about the contents in another post.

Now the Fabric magic can begin. Issue sudo mysqlfabric manage start --daemonize to get Fabric started and then we can add a group. For this example the farm will be called myfarm. mysqlfabric group create myfarm, use group lookup_servers myfarm to be certain the group is as desired.

Add servers to the group with mysqlfabric group add myfarm 10.10.13.x for each of the virtual servers. I set the server_ids to the last IP address number, so 10.10.13.10 was sever_id 10 and so forth.

Now it is time to see how the various severs on the farm are getting along.

mysqlfabric group lookup_servers myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- --------- --------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 SECONDARY READ_ONLY 1.0

Note all the servers are SECONDARY and READ-ONLY.

Was the replication okay? A quick peek to make sure all was covered in that regard.
mysqlrpladmin --master=root:hidave@10.10.13.30 --slaves=root:hidave@10.10.13.10,root:hidave@10.10.13.20 health
WARNING: Using a password on the command line interface can be insecure.
# Checking privileges.
#
# Replication Topology Health:
+--------------+-------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+--------------+-------+---------+--------+------------+---------+
| 10.10.13.30 | 3306 | MASTER | UP | ON | OK |
| 10.10.13.10 | 3306 | SLAVE | UP | ON | OK |
| 10.10.13.20 | 3306 | SLAVE | UP | ON | OK |
+--------------+-------+---------+--------+------------+---------+
# ...done.

Replication looks just spiffy!

Time to create some magic by getting our HA group online.
mysqlfabric group promote myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid finished success result
------------------------------------ -------- ------- ------
c4a60dd8-4bc5-4b52-9f6c-dd5443a95ce8 1 1 1

state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1427828257.29 Triggered by .
4 2 1427828257.33 Executing action (_define_ha_operation).
5 2 1427828257.47 Executed action (_define_ha_operation).
3 2 1427828257.44 Triggered by .
4 2 1427828257.47 Executing action (_find_candidate_fail).
5 2 1427828257.6 Executed action (_find_candidate_fail).
3 2 1427828257.56 Triggered by .
4 2 1427828257.6 Executing action (_check_candidate_fail).
5 2 1427828257.68 Executed action (_check_candidate_fail).
3 2 1427828257.64 Triggered by .
4 2 1427828257.68 Executing action (_wait_slave_fail).
5 2 1427828257.84 Executed action (_wait_slave_fail).
3 2 1427828257.79 Triggered by .
4 2 1427828257.84 Executing action (_change_to_candidate).
5 2 1427828258.17 Executed action (_change_to_candidate).

Hmmm, a lot of information there but IS IT WORKING?? Quick run mysqlfabric group lookup_servers myfarm again!

mysqlfabric group lookup_servers myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

server_uuid address status mode weight
------------------------------------ ----------- --------- ---------- ------
09d13be1-cdd0-11e4-8643-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY 1.0
0f611996-cdd0-11e4-8643-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
11aae7e7-cdd0-11e4-8643-0800273b9c80 10.10.13.30 PRIMARY READ_WRITE 1.0

Yes! We no have a PRIMARY and a pair of SECONDARY servers. But are they healthy?

mysqlfabric group health myfarm
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

uuid is_alive status is_not_running is_not_configured io_not_running sql_not_running io_error sql_error
------------------------------------ -------- --------- -------------- ----------------- -------------- --------------- -------- ---------
09d13be1-cdd0-11e4-8643-0800273b9c80 1 SECONDARY 0 0 0 0 False False
0f611996-cdd0-11e4-8643-0800273b9c80 1 SECONDARY 0 0 0 0 False False
11aae7e7-cdd0-11e4-8643-0800273b9c80 1 PRIMARY 0 0 0 0 False False

And then the High Availability monitoring is started by mysqlfabric group activate myfarm. Those are the steps for setting up a HA Fabric farm.

So lets write a test program, in Python, to see whom we talk to when we connect to the HA farm.

import mysql.connector
from mysql.connector import fabric

fabric_host = "localhost"
fabric_user = "admin"
fabric_password = "hidave"
fabric_group = "myfarm"

cnx = mysql.connector.connect(fabric = {'host' : fabric_host,
'username' : fabric_user,
'report_errors' : True,
'password' : fabric_password
} ,
user='root', password='hidave', autocommit = True, database='world')
cnx.set_property(group="myfarm")
cursor = cnx.cursor()

query = ("SHOW VARIABLEs LIKE 'server_id'")

cursor.execute(query)

for (server_id, value) in cursor:
print server_id, value
cursor.close()
cnx.close()

And when executed the program proudly returned:
python test01.py
server_id 30

Woo-hoo! The test talked to the server at 10.10.13.30! So we no have a three node MySQL Fabric Highly Available server farm.

A Tale of Two Conferences — Midwest PHP and Kansas Linuxfest

MySQL and I were proud to present talks at two recent events — Midwest PHP and Kansas Linuxfest — and it made me realize how vital the smaller shows are to the Opensource Community at large and MySQL in particular. I go to many larger shows like SCaLE where thousands attend. But is the smaller shows where I really get a chance to see what folks are doing with MySQL, learn about new software, and have a reasonable chance to enjoy the ‘hallway track’.

Both these shows would be considered small. Just over two hundred for MidwestPHP and somewhere in the one forties for Kansas. But both shows brought in top speakers from far and wide and combined them with top local talent. Often time the local talents are the real gems as they are often new faces with great ideas. Not all the great ideas are in the Silicon Valley or Austin.

MidwestPHP has been around for a few years and the speakers who attend know we will get spoiled by the organizers. This year many of us were humbled while playing ‘Cards Against Humanity’ by a rabbi at the speakers dinner social. We also know that the audience is coming to learn, will ask hard questions, and you had better bring your ‘A-game’. This is a PHP crowd that is looking for the latest and greatest information on their language of choice but are also actively looking at how to best incorporate CI, Databases, Containers, and other related tech.

This was the first year for the Kansas Linuxfest and in many ways it was like a family reunion. ‘Oh, you are the Linux family from Wichita? We’re the Linux family from Lawrence!’. This first year was as much establishing ties to the various Linux users in the state of Kansas as it was a Linuxfest. Kansas Linux Fest Logo There were a wide variety of subjects covered from Python & Pex to Go and often times two or three great talks where scheduled at the same time.

Both shows will be back in 2016 and you should seriously consider putting time on your calendar for them. If you have a local opensource event or user group in your area, it is well worth the effort to connect with them. It is not only a valuable way to network with others like yourself but you can learn from others.

I recommend going to a least one session on a subject you know little or nothing about. It often will spark ideas to aid in current projects or provide insights on how others approach challenges.

The big shows are great and I enjoy them. But seek out a smaller show as you get a much better chance to interact with those around you. The smaller regional shows also provide better grounds for hunting for folks to add to your professional network.

And for those of you attending Collaborate 15 please see me at the MySQL Demo Pod.