MySQL 8.0 Operational Changes

MySQL 8.0
Operational Changes
Dave Stokes
Community Manager, North America
MySQL Community Team
Copyright © 2019 Oracle and/or its affiliates.

The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material,
code, or functionality, and should not be relied upon in making purchasing decisions. The development,
release, timing, and pricing of any features or functionality described for Oracle’s products may change
and remains at the sole discretion of Oracle Corporation.
Statements in this presentation relating to Oracle’s future plans, expectations, beliefs, intentions and
prospects are “forward-looking statements” and are subject to material risks and uncertainties. A
detailed discussion of these factors and other risks that affect our business is contained in Oracle’s
Securities and Exchange Commission (SEC) filings, including our most recent reports on Form 10-K
and Form 10-Q under the heading “Risk Factors.” These filings are available on the SEC’s website or
on Oracle’s website at http://www.oracle.com/investor. All information in this presentation is current as
of September 2019 and Oracle undertakes no duty to update any statement in light of new information
or future events.
Safe Harbor

MySQL 8.0
is available in
cPanel
and
WHM v88!!
V88
& MySQL 8.0!!!

Our Goal
MySQL 8.0 was a big advancement over
the previous version, MySQL 5.7 and this
presentation is a general overview of some
of the new features.
There are many new facets not covered by
this presentation and hopefully you will be
able to explore them later.

MySQL 5.6
If you are using MySQL 5.6 please note that
it reaches End of Life status for support and
updates in February 2021.
Please upgrade if you are using this version
of MySQL!

What is MySQL?
• Relational Database Management System
• GPLv2 licensed Community Edition
• Licensed Enterprise Edition
Monitoring software, improved backup, at rest encryption, data masking, db firewall, key
chain management, and support
• Also a NoSQL JSON Document Store Database
• Also language connectors, Router, Shell, InnoDB Cluster
• And more!
25 Years old!!

What Happened to MySQL 6.0 and 7.0????
There was an early MySQL 6.0 that withered on the vine and
software was included in the 5.0 series
NDB Cluster has used the 7 series for many years
So engineering thought we earned the 8.0 series which
became generally available in April 2018

A few months ago I did a presentation on
new facets that was mainly developer
oriented and this talk is more
DevOps-centric.

Big Changes in 8.0
Resource groups -- Dedicate cores to classes
of queries, denote in comments
Faster backup -- MySQL Shell utilities dumpSchema &
dumpInstance
Compression -- Replication logs compressed and kept that way
New Temp Table, UTF8MB4 optimized, & more!

CI/CD Model
New releases of MySQL every few months:
• 8.0.21 July 13 2019
• 8.0.20 April 27
• 8.0.19 January 13
• 8.0.18 October 15 2018
• 8.0.17 July 22

Replication - Where Most DevOps folks seem to live
1. InnoDB Cluster
2. Replica Sets
3. Router

InnoDB Cluster Components
• Router is a lightweight Level 4 router
designed to be hosted on your application
platform
• Group Replication creates elastic, highly
available, fault tolerant replication
topologies. Either single-primary
multi-primary modes.
•
• MySQL Shell used for administration

Sandbox Test
Please start with a sandbox cluster to see just how easy it is to
set up InnoDB Cluster

1. Start the MySQL Shell
$ mysqlsh root@localhost

2. Deploy sandbox first node
JS > dba.deploySandboxInstance(3310)
A new MySQL sandbox instance will be created on this host in
/home/dstokes/mysql-sandboxes/3310
Warning: Sandbox instances are only suitable for deploying and
running on your local machine for testing purposes and are not
accessible from external networks.
Please enter a MySQL root password for the new instance: ******
Deploying new MySQL instance...
Instance localhost:3310 successfully deployed and started.
Use shell.connect('root@localhost:3310') to connect to the instance.

3. Deploy sandbox second node

4. Deploy sandbox third node

5. Connect to first node
JS > connect root@localhost:3310
Creating a session to 'root@localhost:3310'
Please provide the password for 'root@localhost:3310': ******
Save password for 'root@localhost:3310'? [Y]es/[N]o/Ne[v]er (default No): y
Fetching schema names for autocompletion... Press ^C to stop.
Closing old connection...
Your MySQL connection id is 12
Server version: 8.0.20 MySQL Community Server - GPL
No default schema selected; type use <schema> to set one.

6. Create cluster
JS > var cluster = dba.createCluster('cpanel')
A new InnoDB cluster will be created on instance 'localhost:3310'.
Validating instance configuration at localhost:3310...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within the same host.
This instance reports its own address as 127.0.0.1:3310
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:33101'. Use the localAddress option to override.
Creating InnoDB cluster 'cpanel' on '127.0.0.1:3310'...
Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to one server failure.

7. Add second node to cluster
JS > cluster.addInstance('root@localhost:3320')
Please provide the password for 'root@localhost:3320': ******
Save password for 'root@localhost:3320'? [Y]es/[N]o/Ne[v]er (default No): yes
NOTE: The target instance '127.0.0.1:3320' has not been pre-provisioned (GTID set is empty).
The Shell is unable to decide whether incremental state recovery can correctly provision it.
The safest and most convenient way to provision a new instance is through automatic clone
provisioning, which will completely overwrite the state of '127.0.0.1:3320' with a physical
snapshot from an existing cluster member. To use this method by default, set the
'recoveryMethod' option to 'clone'.
The incremental state recovery may be safely used if you are sure all updates ever executed in
the cluster were done with GTIDs enabled, there are no purged transactions and the new
instance contains the same GTID set as the cluster or a subset of it. To use this method by
default, set the 'recoveryMethod' option to 'incremental'.

7. Add second node to cluster continued
Please select a recovery method [C]lone/[I]ncremental
recovery/[A]bort (default Clone): C
NOTE: Group Replication will communicate with other members using '127.0.0.1:33201'. Use the localAddress
option to override.
Validating instance configuration at localhost:3320...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within the same host.
This instance reports its own address as 127.0.0.1:3320
Instance configuration is suitable.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.

Adding instance to the cluster...
Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Clone based state recovery is now in progress.
NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.
* Waiting for clone to finish...
NOTE: 127.0.0.1:3320 is being cloned from 127.0.0.1:3310
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY #################################################### 100% Competed
PAGE COPY #################################################### 100% Completed
REDO COPY #################################################### 100% Completed
NOTE: 127.0.0.1:3320 is shutting down...
A new instance will be added to the InnoDB cluster. Depending on the amount of data on the cluster this might take from a few seconds to several hours.

The clone plugin permits
cloning data locally or
from a remote MySQL
server instance.
Cloned data is a
physical snapshot of
data stored in InnoDB
that includes schemas,
tables, tablespaces, and
data dictionary
metadata.

* Waiting for server restart... ready
* 127.0.0.1:3320 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 59.62 MB transferred in about 1 second (~59.62 MB/s)
Incremental state recovery is now in progress.
* Waiting for distributed recovery to finish...
NOTE: '127.0.0.1:3320' is being recovered from '127.0.0.1:3310'
* Distributed recovery has finished

8. Add third node to cluster continued
JS > cluster.addInstance('root@localhost:3330')

JS > cluster.status()
{
"clusterName": "cpanel",
"defaultReplicaSet": {
"name": "default",
"primary": "127.0.0.1:3310",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate
up to ONE failure.",
"topology": {
"127.0.0.1:3310": {
"address": "127.0.0.1:3310",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.20"
},
"127.0.0.1:3320": {
"address": "127.0.0.1:3320",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE",
"version": "8.0.20"
},
"127.0.0.1:3330": {
"address": "127.0.0.1:3330",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE",
"version": "8.0.20"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember":
"127.0.0.1:3310"

9. Start Router
$ mysqlrouter --bootstrap root@localhost:3310 --directory
/tmp/myrouter&
Please enter MySQL password for root:
# Bootstrapping MySQL Router instance at '/tmp/myrouter'...
- Creating account(s) (only those that are needed, if any)
- Verifying account (using it to run SQL queries that would be run by Router)
- Storing account in keyring

10. Start Router continued
- Adjusting permissions of generated files
- Creating configuration /tmp/myrouter/mysqlrouter.conf
# MySQL Router configured for the InnoDB Cluster 'cpanel'
After this MySQL Router has been started with the generated
configuration
$ mysqlrouter -c /tmp/myrouter/mysqlrouter.conf&

10. Start Router continued
The cluster 'cpanel' can be reached by connecting to:
## MySQL Classic protocol mysql -u root -p -P 6446
- Read/Write Connections: localhost:6446
- Read/Only Connections: localhost:6447
## MySQL X protocol mysql -u root -p -P 64460
- Read/Write Connections: localhost:64460
- Read/Only Connections: localhost:64470

Architecture
Place Router on the same
platform as you application.
You application does not need
to know what is behind the
router and probably should not
care. This way you can scale
without changing application.

Want Multi-Primary?
JS > cluster.switchToMultiPrimaryMode()
Switching cluster 'cpanel' to Multi-Primary mode...
Instance '127.0.0.1:3330' was switched from SECONDARY to PRIMARY.
Instance '127.0.0.1:3310' remains PRIMARY.
Instance '127.0.0.1:3320' was switched from SECONDARY to PRIMARY.
The cluster successfully switched to Multi-Primary mode.

JS > cluster.status()
{
"clusterName": "cpanel",
"defaultReplicaSet": {
"name": "default",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is
ONLINE and can tolerate up to ONE
failure.",
"topology": {
"127.0.0.1:3310": {
"address":
"127.0.0.1:3310",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE",
"version": "8.0.21"
},
"127.0.0.1:3320": {
"address": "127.0.0.1:3320",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE",
"version": "8.0.21"
},
"127.0.0.1:3330": {
"address": "127.0.0.1:3330",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE",
"version": "8.0.21"
}
},
"topologyMode": "Multi-Primary"
},
"groupInformationSourceMember": "127.0.0.1:3310"
}

MySQL Router
Failover
Typically, a highly available MySQL setup
consists of a single primary and multiple
replicas and it is up to the application to
handle failover, in case the MySQL primary
becomes unavailable. Using MySQL Router,
application connections will be transparently
routed based on load balancing policy, without implementing custom application code.
Load Balancing
MySQL Router provides additional scalability and performance by distributing database
connections across a pool of servers in a round-robin fashion.

Production InnoDb Cluster
Double check system configuration (run on all nodes)
● dba.configureLocalInstance("root@localhost:3306")
Start the Cluster
● var cluster = dba.createCluster('testCluster')
● cluster.addInstance('icadmin@ic-2:3306')
● cluster.addInstance('icadmin@ic-3:3306')
● mysqlrouter --bootstrap clusteradmin@db1:3306 --directory
myrouter --user=root

Replica Set
InnoDB ReplicaSet a quick and easy way to get MySQL
replication and MySQL Router up and running, making it well
suited to scaling out reads, and provides manual failover
capabilities in use cases that do not require the high availability
offered by InnoDB cluster.
ReplicaSet automates a lot of the tasks found in traditional
asynchronous replication.

Replica Set
An InnoDB ReplicaSet has several limitations compared to a InnoDB cluster and thus, it is recommended that
you deploy InnoDB cluster wherever possible. Generally, a InnoDB ReplicaSet on its own does not provide high
availability. Among the limitations of InnoDB ReplicaSet are:
● No automatic failover. In events where the primary becomes unavailable, a failover needs to be triggered
manually using AdminAPI before any changes are possible again. However, secondary instances remain
available for reads.
● No protection from partial data loss due to an unexpected halt or unavailability. Transactions that have not
yet been applied by the time of the halt could become lost.
● No protection against inconsistencies after a crash or unavailability. If a failover promotes a secondary while
the former primary is still available (for example due to a network partition), inconsistencies could be
introduced because of the split-brain.

configure ReplicaSet
JS> dba.configureReplicaSetInstance()
JS> var rs = dba.createReplicaSet("example")
JS> rs.addInstance('rsadmin@host2')

configure ReplicaSet
JS> dba.configureReplicaSetInstance()
JS> var rs = dba.createReplicaSet("example")
JS> rs.addInstance('rsadmin@host2')
As an alternative to creating a new InnoDB ReplicaSet, you can
also adopt an existing replication setup using the adoptFromAR
option with dba.createReplicaSet().

Other things to note
These can really speed up your queries or
make life easier

Resource Groups
CREATE RESOURCE GROUP Batch -- assumes a system with at least 4 CPUs
TYPE = USER VCPU = 2-3 THREAD_PRIORITY = 10;
SET RESOURCE GROUP Batch;
or
INSERT /*+ RESOURCE_GROUP(Batch) */ INTO t2 VALUES(2);

Optimizer Hints
SELECT /*+ JOIN_ORDER(t1, t2) */ ... FROM t1, t2;
Optimizer hints can be specified within individual statements.
Because the optimizer hints apply on a per-statement basis, they
provide finer control over statement execution plans than can be
achieved using optimizer_switch.
For example, you can enable an optimization for one table in a
statement and disable the optimization for a different table.

User_attributes - how to ID accounts
CREATE USER 'dstokes'@'localhost'
IDENTIFIED by 'S3cr3t!'
COMMENT '{ "user" : "Dave" }';
And the information is stored in a column named User_attributes.
select User_attributes from user WHERE
User='dstokes'G
*************************** 1. row
***************************

User_attributes - how to ID accounts
ALTER USER 'jack'@'localhost'
ATTRIBUTE '{ "foo" : "Example revised" }';
SELECT User_attributes from user where User='jack';
+---------------------------------------------------------+
| User_attributes |
+---------------------------------------------------------+
| {"metadata": {"foo": "Example revised", "test": "yes"}} |
+---------------------------------------------------------+

REDO Logging on/off 8.0.21
Redo logging can now be enabled and disabled using ALTER
INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG syntax.
This functionality is intended for loading data into a new MySQL
instance.
Disabling redo logging helps speed up data loading by avoiding
redo log writes.

Binary log transaction compression
When binary log transaction compression is enabled, transaction payloads are compressed using
the zstd algorithm, and then written to the server's binary log file as a single event (a
Transaction_payload_event).
Compressed transaction payloads remain in a compressed state while they are sent in the
replication stream to replication slaves, other Group Replication group members, or clients such as
mysqlbinlog.
They are not decompressed by receiver threads, and are written to the relay log still in their
compressed state.
Binary log transaction compression therefore saves storage space both on the originator of the
transaction and on the recipient (and for their backups), and saves network bandwidth when the
transactions are sent between server instances.

Dual Passwords
ALTER USER 'dave'@'deardave.xyz' IDENTIFIED BY
'deardave2' RETAIN CURRENT PASSWORD;
In the mysql.user table there is now a JSON column named
User_attributes that now has the secondary password:
{"additional_password":
"$A$005$;H7u001bu001bu0006<`qFRUtNRxT
Zu0003Ya/iej8Az8LoXGTv.dtf9K3RdJuaLFtXZHBs3/DntG2"
}

You need this book!
MySQL 8 Query Performance Tuning:
A Systematic Method for Improving
Execution Speeds
Jesper Wisborg Krogh
ISBN-13: 978-1484255834
ISBN-10: 1484255836

MySQL on the Internet
● MySQLCommunity.slack.com
● Forums.mysql.com
● MySQL.com & Planet.MySQL.com
● @MySQL

Thank You
Dave Stokes
Community Manager
David.Stokes @ Oracle.com
@Stoker
ElephantDolphin. blogger.com
slideshare.net/davidmstokes

Thank You
Dave Stokes
Community Manager
David.Stokes @ Oracle.com
@Stoker
ElephantDolphin.
blogger.comslideshare.net/davidmstokes
Q&A??

MySQL 8.0 Operational Changes

Recommended

More Related Content

What's hot (20)

Similar to MySQL 8.0 Operational Changes (20)

More from Dave Stokes (11)

Recently uploaded (19)

MySQL 8.0 Operational Changes