docs: recommend InnoDB over MEMORY engine for Boost tables

Large installations and those using the multiprocessing update feature
(introduced in 1.2.17) are susceptible to race conditions and lock
contention when using MEMORY engine. InnoDB with SSD/NVMe storage is
now the default recommendation.

Also fix:
- 'formally' -> 'formerly'
- duplicate 'the the'
- 'Utilityes' -> 'Utilities'
- invalid two-table ALTER TABLE SQL (comma-separated table list)

Closes #106

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>

Author: somethingwithproof

Boost.md

@@ -2,11 +2,11 @@
 
 ## Summary
 
-Cacti Performance Settings, formally known as `boost` are available to support
+Cacti Performance Settings, formerly known as `boost` are available to support
 very large Cacti installations, and are required for supporting the multiple
 **Data Collector** architecture that Cacti affords.
 
-Designed years ago, Boosts intent was to reduce the the main data collectors
+Designed years ago, Boosts intent was to reduce the main data collectors
 cycle time by caching writes to disk, and those writes would be handled by an
 out of band process currently known as `poller_boost.php`.
 
@@ -31,12 +31,21 @@ on demand by the Cacti Administrator. They include:
 
 ## Prerequisites
 
+> **Recommendation**: For most installations, especially those using the
+> **multiprocessing update** feature introduced in Cacti 1.2.17, or any
+> deployment with multiple Data Collectors, use **InnoDB** for all Boost tables.
+> The MEMORY engine can cause race conditions between concurrent processes
+> competing for memory table locks, which leads to polling backlogs and data
+> loss on busy systems. InnoDB with SSD or NVMe storage performs comparably and
+> avoids these failure modes. MEMORY tables are also incompatible with MariaDB
+> Galera and MySQL replication.
+
 In its initial design the Boost process leveraged MySQL Memory Tables to
-increase overall performance, and to reduce writing data to disk. This is still
-a valid case however, with improvements in InnoDB performance over the years
-combined with Flash storage, the need for using MySQL Memory Tables has
-diminished. In some cases, for example when using MariaDB Galera, or MySQL
-Master/Slave replication, it can not be used.
+increase overall performance, and to reduce writing data to disk. With
+improvements in InnoDB performance over the years combined with Flash storage,
+the need for MySQL Memory Tables has diminished. The sections below document
+MEMORY table sizing for sites that have an explicit reason to use it, but InnoDB
+is the default and recommended engine.
 
 If you do wish to use Memory you have to pay close attention to the amount of
 data that will be cached in your design. You should periodically check that you
@@ -61,7 +70,7 @@ important. That will be explained in more detail later on in this chapter.
 ## Checking how your system is configured
 
 To see how your system is configured, you can goto
-`Console > Utilityes > System Utilities > View Boost Status` option, when you go
+`Console > Utilities > System Utilities > View Boost Status` option, when you go
 there, you will see an image similar to that below.
 
 ![Boost Status Screen](images/boost-status1.png)
@@ -123,13 +132,13 @@ The next step would me to modify the structure of your `poller_output` and
 `poller_output_boost` tables. You would do this by doing the following:
 
 ```sql
-ALTER TABLE poller_output,
-    MODIFY column output varchar(50) NOT NULL default ""
-    ENGINE=memory;
+ALTER TABLE poller_output
+    MODIFY COLUMN output varchar(50) NOT NULL DEFAULT '',
+    ENGINE = MEMORY;
 
-ALTER TABLE poller_output_boost,
-    MODIFY column output varchar(50) NOT NULL default ""
-    ENGINE=memory;
+ALTER TABLE poller_output_boost
+    MODIFY COLUMN output varchar(50) NOT NULL DEFAULT '',
+    ENGINE = MEMORY;
 ```
 
 As previously mentioned, its also important that the `poller_output` table is
@@ -178,10 +187,14 @@ Then, save the file, and restart MySQL. Once this is done, you are ready to
 
 ## Flushing the Boost Cache
 
-If you are planning on system maintenance if you are using MEMORY storage in
-MySQL or MariaDB, you should flush your Boost Cache before your system is taken
-offline for maintenance. To do this, you simply login to the Cacti system as
-root, and flush the Cache using the commands below
+> **Warning**: MEMORY tables are cleared on every MySQL/MariaDB restart. If you
+> are using MEMORY storage, always flush the Boost Cache before taking the
+> database offline. Failure to do so will result in loss of all buffered poller
+> data since the last flush.
+
+If you are planning on system maintenance and are using MEMORY storage in
+MySQL or MariaDB, flush your Boost Cache before the system is taken offline.
+Login to the Cacti system as root and run the following:
 
 ```console
 cd /var/www/html/cacti