ChapTEr 8 ■ DEmonsTraTion of high availabiliTy TEChniquEsHigh Availability IOT Nodes
You have seen a number of techniques using MySQL replication that you can leverage to achieve a level
of high availability (reliability) in your IOT solution. But these cover the database availability and not the
underlying hardware for your IOT nodes. This section examines two examples for how to achieve high
availability in your IOT nodes.
You will see an example of how to make a redundant and automatic recovery of a data collector failure
as well as a data aggregator that can cache data should its connection to the database fail. The examples use
Arduino microcontrollers, but the concepts can be applied to other microcontrollers, and thus you should
be able to duplicate these concepts in your own solutions.
Example: Redundant Data Collectors
One thing that you will eventually encounter if you work with microcontrollers long enough on increasingly
complex IOT solutions is that sometimes the microcontroller will go wonky^6 or completely wig out.^7 This
could be because of a power failure, unclean power supply, tampering, poor programming, memory
corruption, or just plain fate. I’ve had microcontrollers that have run seemingly forever and others that turn
hinky within a few days. Whatever the case, microcontrollers can and do indeed occasionally fail.
One way to combat this and to ensure our solution is more reliable (and high available to a degree) is to
build redundancy into our hardware. We can do this using a master/slave setup of two microcontrollers. Both
microcontrollers would have the same type of sensors (if not the same sensors^8 ), but only the master would
be writing the data to the database. Furthermore, we want to make a data collector redundant with automatic
failover to the slave so that if the master fails, the slave takes over and we do not lose any significant data.
Yes, we are talking about creating a simple replication protocol for the master and slave to
communicate. Let’s consider how we would do this.
Overview of the Design
There are many ways we could implement a simple protocol between the master and slave. In this case, we’ll
keep it simple and use the concept of a heartbeat. This is a simple message transmitted by one server and
acknowledged on another. The idea is if the heartbeat fails or is missed after a significant time period, the
second server can assume the first server has failed or gone wonky, has gone hinky, or has wigged out entirely.
Fortunately, we can do this with a capability built into the Arduino: the I2C (pronounced “eye-two-see”)
interface bus with the wire protocol. The I2C bus uses two pins or wire (sometimes called two-wire): the
Serial Data Line (SDA on pin 4) and Serial Clock Line (SCL on pin 5). The interface allows for multiple
devices to connect by registering a device number when initiated. Indeed, there are a great number of
devices including sensors that use the I2C interface.
■Caution if you are using a uno, leonardo, or similar board with the newer header layout, the sDa and sCl
pins are located above pin 13 (D2 and D3). similarly, larger boards like the mega or Due have the i2C interface
in a different location (D20 and D21). be sure to check the header layout of your board; otherwise, you could be
faced with a frustrating debugging session.^9
(^6) Not to be confused with hinky, which is worse.
(^7) A highly technical description of erratic behavior.
(^8) Not recommended, but I’ve seen it work well in experiments. I would use duplicate sensors.
(^9) Can you guess how I know this? Yep. I was ready to skeet shoot my Leonardo until I remembered the pin layout was
different. Use enough Arduino boards, and you may find you’ll want to do the same!