Table of Contents

Mastering MariaDB

Credits

About the Author

About the Reviewers

www.PacktPub.com

Support files, eBooks, discount offers, and more

Why subscribe?

Free access for Packt account holders

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Downloading the example code

Errata

Piracy

Questions

1. Understanding the Essentials of MariaDB

The MariaDB architecture

The command-line client

Storage engines

XtraDB and InnoDB

TokuDB

MyISAM and Aria

Other engines

Logs

MariaDB caches

InnoDB data structures

Authentication and security

The information_schema database

The performance_schema database

Compatibility with MySQL and other DBMS

MariaDB resources

Summary

2. Debugging

Understanding error conditions in MariaDB

The SQLSTATE value

The error number

The error message

The custom errors

The SHOW WARNINGS and SHOW ERRORS statements

The diagnostics area

The GET DIAGNOSTICS statement

The error log

The error log format

A troubleshooting example with the error log

System logs

The general query log

The file format of the general query log

The general_log table

Debugging examples with the general query log

Maintenance of the server logs

Flushing logs

Rotating the file-based logs

Rotating the table-based logs

The SQL_ERROR_LOG plugin

Tips on debugging stored programs

Debugging stored programs using the SQL_ERROR_LOG plugin

Summary

3. Optimizing Queries

The slow query log

The file format of the slow query log

The slow_log table

Explaining the pt-query-digest command from Percona Toolkit

Introducing indexes

Table statistics

Storage engines and indexes

Working with the EXPLAIN statement

Understanding the output of EXPLAIN

Simple SELECT statements

Internal temporary tables or files

The UNION queries

Simple index access methods

Index optimizations of the JOIN clause

Optimization of subqueries

Summary

4. Transactions and Locks

The InnoDB locks

The lock modes

Lock types

Diagnosing locks

Locks used by various SQL statements

Reads consistency

The non-repeatable reads

Phantom rows

Consistent reads

Locking reads

Deadlocks

Transactions

The transactions life cycle

Transactions isolation levels

The READ UNCOMMITTED isolation level

The READ COMMITTED isolation level

The REPEATABLE READ isolation level

The SERIALIZABLE isolation level

Transactions access modes

Metadata locks

Summary

5. Users and Connections

User accounts

Setting permissions using roles

Connecting MariaDB through Secure Socket Layer

Authentication plugins

Activating the pool of threads

Monitoring the pool of threads

Configuring the threadpool implementation

Configuring the pool of threads on Unix

Configuring the pool of threads on Windows

Tuning the configuration variables

Unblocking a blocked pool of threads

Monitoring connections

States of the process

Aborting connections

Summary

6. Caches

InnoDB caches

InnoDB pages

The InnoDB buffer pool

Old and new pages

Buffer pool instances

Dirty pages

The read ahead optimization

Diagnosing the buffer pool performance

Dumping and loading the buffer pool

The InnoDB change buffer

Explaining the doublewrite buffer

MyISAM key cache

LRU and the midpoint insertion strategy

Key cache instances

Segmented key cache

Preloading indexes into the cache

Aria page cache

The query cache explained

Configuring the query cache

Information on the status of the query cache

Explaining the subquery cache

Alternative query caching methods

The table open cache

Per-session buffers

Summary

7. InnoDB Compressed Tables

An overview of the InnoDB compression

InnoDB compression requirements

Explaining the file-per-table mode

A brief on InnoDB file formats

Creating InnoDB compressed tables

Explaining the implementation of the InnoDB compression

Monitoring the InnoDB compression performance

The INNODB_CMPMEM table

The INNODB_CMP_PER_INDEX table

The INNODB_CMP table

Other compression solutions

Summary

8. Backup and Disaster Recovery

Types of backups

Logical and physical backups

Hot and cold backups

Complete and incremental backups

Backups and replication

Steps to be followed before performing backups

Creating a dump file with mysqldump

Delimited text backups

The --tab option of the mysqldump command

Loading a dump file with the mysqlimport command

Creating a text-delimited file with the SELECT … INTO OUTFILE command

Dumping a table definition with the SHOW CREATE TABLE command

Loading a dump file with the LOAD DATA INFILE statement

Separator options and clauses

An example to create and restore dump files

Performing a backup using a CONNECT or CSV engine

Physical backups

Which files should be copied?

Table files

Logfiles

Configuration files

Hot physical backups

Filesystem snapshots

Incremental physical backups with the rsync command

Copying files when the server is running

Using the binary log for incremental backups

Percona XtraBackup

Performing backups

Complete backups

Partial backups

Preparing backups

Preparing complete backups

Preparing partial backups

Restoring backups

Restoring complete backups

Restoring partial backups

Securing backups

Repairing tables

Recovering InnoDB tables

Checking tables

Transaction logs

Forcing data recovery

Repairing non-InnoDB tables

The CHECK TABLE statement

The REPAIR TABLE statement

Repairing CSV tables

Repairing tables with the myisamchk and aria_chk tools

MyISAM and Aria autorecovery

Summary

9. Replication

An overview of replication

How replication works

Replication threads

Parallel replication

Slave logs

Choosing a binary log format

Statement-based binary logging

Row-based binary logging

The MIXED binary logging format

The binary logging of stored programs

Configuring replication

Configuring a new replication master

Configuring a new replication slave

Starting a slave

Checking whether a slave is running

Reconfiguring an existing slave

Importing the data into a master

Importing the data into a slave from a master

Dumping data from a master

Dumping data from a slave

Filtering binary log events

The SET SQL_LOG_BIN statement

The @@skip_replication variable

Filtering the replication of events on the slaves

Checksums of the binary log events

Configuring parallel replication

Delaying a slave

Multisource replication

Replication logs

Rotating the binary log

Rotating the relay log

The slave status logs

Checking the replication for errors

The CHECKSUM TABLE statement

The pt-table-checksum tool

Files checksum

Query checksum

Troubleshooting

A slave does not start

A slave lags behind

Summary

10. Table Partitioning

Support for partitioning

Partitioning types and expressions

Partitioning expressions

Indexes and primary keys

Partition names

Partitioning types

The RANGE type

The LIST type

The COLUMNS keyword

The HASH and KEY types

The LINEAR keyword

Splitting into subpartitions

Administering partitioned tables

Obtaining information about partitions

Changing partitions' definitions

Modifying RANGE and LIST partitions

Modifying HASH and KEY partitions

Copying data between a partition and a table

Maintenance operations statements

Partitions' physical files

Query optimizations

Partition pruning

Partition selection

Summary

11. Data Sharding

Distributing files between multiple disks

Determining the path of table files

InnoDB logfiles

Configuring the undo log

Configuring the redo log

The FEDERATEDX and CONNECT storage engines

Creating a FEDERATEDX table

Defining a link to a remote server

Creating a MYSQL CONNECT table

Sending SQL statements to a remote server

Merging multiple CONNECT MYSQL tables

The SPIDER storage engine

Explaining the working of the SPIDER storage engine

Installing the SPIDER storage engine

Creating a SPIDER table

Logging of queries and errors

Executing arbitrary statements on remote servers

Explaining the spider_direct_sql() function

Explaining the spider_bg_direct_sql() function

Summary

12. MariaDB Galera Cluster

MariaDB Galera Cluster key concepts

An overview of Galera Cluster

Synchronous replication

Setting up a cluster

Requirements

Installation

Starting the nodes

Determining a node URL

Node provisioning

State Snapshot Transfer

Incremental State Transfer

The split brain problem

The Galera arbitrator

Configuring the cluster

Explaining the important Galera system variables

Generic cluster settings

Performance and reliability

Settings affecting the behavior of State Snapshot Transfer

Dealing with Galera limitations

Setting the wsrep parameters

Monitoring and troubleshooting

Notification scripts

Checking the status variables

The health of a cluster

Individual node health

The health of a replication

Network performance

Load balancing

Listing the limitations of Galera Cluster

Galera Load Balancer

Summary

Index

Mastering MariaDB

Mastering MariaDB

Copyright © 2014 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

First published: September 2014

Production reference: 1170914

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham B3 2PB, UK.

ISBN 978-1-78398-154-0

www.packtpub.com

Cover image by Karl Moore (karl@karlmoore.co.uk)

Credits

Author

Federico Razzoli

Reviewers

Josh King

Daniel Parnell

Giacomo Picchiarelli

Philipp Wollermann

Commissioning Editor

Kunal Parikh

Acquisition Editor

Reshma Raman

Content Development Editor

Akshay Nair

Technical Editor

Mrunmayee Patil

Copy Editors

Sarang Chari

Mradula Hegde

Adithi Shetty

Project Coordinator

Swati Kumari

Proofreaders

Stephen Copestake

Paul Hindle

Joanna McMahon

Indexer

Hemangini Bari

Graphics

Abhinash Sahu

Production Coordinator

Shantanu N. Zagade

Cover Work

Shantanu N. Zagade

About the Author

Federico Razzoli is a software developer, database consultant, and free software supporter. He has been working on websites and database applications since 2000, and has used MySQL extensively throughout this period. He is now an active member of the MariaDB community.

About the Reviewers

Josh King works as the Senior Systems Software Engineer for Kualo Web Hosting and has been using and administering databases for well over a decade. He is also an active developer specializing in system performance and the Linux kernel. He has been a contributor to the numerous Linux and open source projects as well as a member of several organizations, such as the League of Professional System Administrators (LOPSA) and the Free Software Foundation.

He works with cloud and high-availability solutions, as well as Windows and BSD platforms. He is a recipient of the LOPSA Professional Recognition award for excellence and professionalism in Information Technology, and has written papers on numerous subjects dealing with the performance and optimization of the Linux operating system.

He currently resides in Texas with his wife and children.

Daniel Parnell has been messing around with computers since a very early age. He started working with an AIM-65, through a Commodore VIC-20, Commodore 64, Apple IIe, Commodore Amiga, an ICL Concurrent CP/M86 machine, and Apple Mac Plus to various PCs and Macs today.

Of late, Daniel has been working on web applications for the health care industry using Ruby on Rails, and building a rich web application using a JavaScript frontend and an Erlang backend.

When Daniel is not coding or tinkering with electronic gadgets around the house, he is spending time with his family. His son died late last year at the age of 6 of an untreatable neurodegenerative disorder called Battens disease.

Giacomo Picchiarelli is a test and software engineer with 6 years of experience in designing data-driven applications and MySQL administration. He has a strong background in Linux systems and test-driven development.

Philipp Wollermann is a Software Engineer currently working for Google in Germany. His experience with MariaDB comes from having run his own Linux-based web hosting business for over 5 years, and from working for CyberAgent, Inc. in Tokyo, where he helped optimize web applications and database performance.

www.PacktPub.com

Support files, eBooks, discount offers, and more

For support files and downloads related to your book, please visit www.PacktPub.com.

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at for more details.

At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.

http://PacktLib.PacktPub.com

Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.

Why subscribe?

Fully searchable across every book published by Packt

Copy and paste, print, and bookmark content

On demand and accessible via a web browser

Free access for Packt account holders

If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view 9 entirely free books. Simply use your login credentials for immediate access.

Preface

It is said that the most advanced technologies are invisible to the user. This is certainly true in the case of database management systems. Databases are one of the most important invisible technologies that make things happen. They are everywhere around us and we use them several times a day; though we can't see them. For example, we use them when we make a phone call, or reserve a hotel room, or visit a website, or use some electronic device. Sometimes, these databases are big and complex. And, in many cases, they are managed by MySQL or one of its forks such as MariaDB.

MySQL is mainly known for being one of the four components of the LAMP stack, that is, Linux, Apache, MySQL, and PHP—the most common technologies that make websites work. And that's the reason why many people, who aren't even associated with Information Technology, have heard about MySQL. In fact, MySQL development started in the 80s but the software became famous only with the birth of dynamic websites between 2000 and 2001. It is open source, free, and very simple to learn and administrate. It was exactly what the new websites needed.

Despite its substantial simplicity, MySQL's features have grown fast. It was criticized by PostgreSQL supporters because it did not support many key features of DBMSs, such as transactions and foreign keys. In spite of this being true at that time, MySQL had several unique features, which were extremely useful for a large amount of users. For example, it supported replication 10 years before PostgreSQL! It was also reliable and fast. And as time went by, MySQL became a complete, feature-rich relational DBMS.

Why then did Monty Widenius, the creator of MySQL, leave the project to start a fork called MariaDB? That was because, in 2005, Oracle bought the InnoDB storage engine. In 2008, Sun Microsystems bought MySQL, which in turn was bought by Oracle in 2009. Since that acquisition, MySQL belongs to its biggest competitor: a big corporation whose business is mainly proprietary, high-cost software.

To be fair, we must make it clear that Oracle is investing substantial resources on the MySQL technology, and did a great job in some areas, especially InnoDB. However, some uncertainty remains; is Oracle selecting the new features to avoid the users of their main product switching to MySQL? Will Oracle always invest in MySQL and keep it open source? Only Oracle managers know the answers to these questions.

What we know for sure is that MySQL is now less open than it used to be in the past. The public bug database is not used by Oracle employees and contains obsolete information. No information or test cases are released about security holes. The repositories are updated less often. And some community-oriented sites, such as a public wiki edited by the community, that contain vast information about MySQL do not exist anymore.

On the contrary, the strength of MariaDB is its continuous collaboration with the community. Very important new features such as multisource replication and roles have been initially developed by community members. MariaDB's bug tracking and project management software allows us to know which bugs or new features are being processed, what the new versions will look like, and when they will be released. Some developers actively communicate with users via the mailing lists and IRC channel. And while MySQL documentation has always been proprietary, MariaDB documentation has free licenses and can be improved by the community using a public wiki.

Most importantly, MariaDB Foundation exists. It is similar to other foundations related to free software projects such as the Apache Foundation. Monty Widenius himself is a member of the board of directors. The purpose of the foundation is to safeguard the MariaDB source code, and guarantee that it will always remain free. It also promotes MariaDB and its ecosystem, maintaining the MariaDB Knowledge Base. The website of the MariaDB Foundation is https://mariadb.org/.

The MariaDB and MySQL teams follow diverging roads. The starting point is the same: the state of MySQL in 2009. However, while the MySQL road is going towards a less open zone, MariaDB is a perfectly open project. The results of this openness are positive from a technical point of view, too. MariaDB developers and MariaDB users are both interested in constantly improving the server, and they collaborate to achieve this goal.

This book provides the knowledge needed to administrate the MariaDB server and clusters of servers. It will help you master database development on the MariaDB server. It shows you how to maintain a MariaDB server, taking advantage of its most recent features as well as the battle-tested functionalities inherited from MySQL. The book starts with an overview of the basic features and mechanisms that an advanced user should know. This includes diagnosing and solving most of the real-life problems, such as MariaDB errors, logs, and locks. You will learn how to improve the performance of a server by identifying slow queries. The book then covers how to choose and set up a proper backup plan and recover data when disaster occurs. Sharing your data through several servers using replication, MariaDB Galera Cluster, and the SPIDER storage engine will be dealt in detail. By the end of this book, the reader will be able to configure MariaDB servers, diagnose, as well as troubleshoot the standard transactional problems, and execute database maintenance. Both of these features imported from MySQL, as well as MariaDB's unique features, are covered in the book. Plugins and tools developed by the community are also explained.

MariaDB is ready to make things work, even in situations where high performance and high availability are critical. Get ready to make MariaDB work!

What this book covers

Chapter 1, Understanding the Essentials of MariaDB, discusses some of the key concepts and components of MariaDB, such as storage engines and logging. The most important resources for MariaDB professionals are also listed in this chapter.

Chapter 2, Debugging, explains how to debug SQL statements in MariaDB. It discusses how MariaDB generates errors and logs that can be used to find bugs.

Chapter 3, Optimizing Queries, is an overview on query optimization. First, it shows how to find slow queries that need be optimized. Then, it discusses the most important algorithms used by the MariaDB optimizer to execute a query, such as the index merge and the subquery optimization algorithms.

Chapter 4, Transactions and Locks, deals with concurrency. It explains how MariaDB uses locks to guarantee a proper isolation level for each transaction, and how these locks affect performance.

Chapter 5, Users and Connections, discusses how to manage user accounts and their activities in MariaDB. It covers permissions, the allocation of resources on a user basis, authentication methods, SSL connections, and the pool of threads.

Chapter 6, Caches, explains the caches used by the general purpose storage engines: InnoDB buffer pool, MyISAM key cache, and Aria page cache. Then, it explains the query and subquery caches and discusses alternative methods to cache the results of queries.

Chapter 7, InnoDB Compressed Tables, discusses InnoDB compressed tables. It shows how to create compressed tables and how to monitor their performance. Finally, it compares the different compression solutions available in MariaDB.

Chapter 8, Backup and Disaster Recovery, explains the backup methods provided by MariaDB and some third-party tools. The chapter discusses how to choose a backup plan, how to perform the different backup types, and how to restore backups when needed.

Chapter 9, Replication, illustrates how to set up and maintain a replication environment. The latest features of replication from MariaDB 10.0 are included, namely parallel replication and multisource replication.

Chapter 10, Table Partitioning, shows how to split big tables into multiple partitions, perhaps located on different storage devices. The characteristics of different partitioning types are explained, as well as the optimizations allowed by the different partition types.

Chapter 11, Data Sharding, discusses the main methods to distribute data across multiple disks or servers. The storage engines that allow reading and writing data onto remote servers are illustrated here: SPIDER, FederatedX, and CONNECT.

Chapter 12, MariaDB Galera Cluster, covers the MariaDB distribution of the Galera Cluster technology. It explains how to set up a cluster, add new nodes, monitor performance, and identify the most common problems.

What you need for this book

To put the topics of this book into practice, we need a personal computer running any operating system supported by MariaDB: Linux/UNIX, Mac OS X, or Windows. Linux is preferred because this system is most used for MariaDB and the book focuses on it. However, the commands should run unmodified on any Unix system; Windows is also mentioned where necessary.

MariaDB and MariaDB Galera Cluster can be downloaded from MariaDB's official site. The required third-party software is available on the sites mentioned in the relevant chapters. The mentioned system commands should be included in all the Linux distributions.

Who this book is for

This book is for intermediate MariaDB or MySQL users who need a more thorough comprehension of MariaDB, to administer a MariaDB server, or set of servers. Expert users of other relational DBMSs can also read this book, though they are encouraged to learn MariaDB basics using the MariaDB Knowledge Base or a MariaDB or MySQL beginner's book.

In particular, the reader of this book should already know the following topics:

The basic concepts of a relational DBMS

SQL language, at least at a basic level

The syntax and structure of configuration files

Knowledge of the following topics is not necessary to understand the book but is recommended to get the best from it:

How to write a script to automate tasks on Linux or Windows

How to write a script or program that interacts with MariaDB

MariaDB stored programs: stored procedures, events, and triggers

Conventions

In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.

Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: The SHOW PROCESSLIST statement returns information about the active connections.

A block of code is set as follows:

EXPLAIN [EXTENDED] ;

Any command-line input or output is written as follows:

root@this:/usr/local/mysql# mysqldump -uroot -proot test customer --tab=/tmp --fields-terminated-by=, --fields-enclosed-by=' --fields-escaped-by=/

New terms and important words are shown in bold.

Note

Warnings or important notes appear in a box like this.

Tip

Tips and tricks appear like this.

Reader feedback

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an e-mail to <feedback@packtpub.com>, and mention the book title via the subject of your message.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.

Customer support

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Errata

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.

Piracy

Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at <copyright@packtpub.com> with a link to the suspected pirated material.

We appreciate your help in protecting our authors, and our ability to bring you valuable content.

Questions

You can contact us at <questions@packtpub.com> if you are having a problem with any aspect of the book, and we will do our best to address it.

Chapter 1. Understanding the Essentials of MariaDB

This chapter provides a generic overview of the MariaDB architecture. Note that this description is not meant to teach MariaDB to new users; some knowledge of the software is necessary to fully understand this book.

The following topics will be discussed in this chapter:

The MariaDB architecture

The workflow of SQL statement processing

Usage and tricks of the command-line client used, in all chapters of this book

Storage engines and their characteristics

Logs

Caches

User authentication and permissions

The INFORMATION_SCHEMA and PERFORMANCE_SCHEMA system databases

Compatibility with MySQL and other DBMS

Resources on the Web

The MariaDB architecture

MariaDB is a community-driven fork of MySQL that was started in 2009 by Monty Widenius, the original author of MySQL, after the old project was acquired by Oracle. The first version of MariaDB was based on MySQL 5.1, and the improvements to MySQL base code are regularly merged into the MariaDB project. Other features are also merged from the Percona Server, another fork that is very similar to the mainstream product.

The most important Percona feature merged into MariaDB is XtraDB, a fork of the InnoDB storage engine. InnoDB is the default storage engine in modern MySQL and MariaDB versions. XtraDB fixes bugs that are still present in InnoDB before the official bug fixes are released by Oracle. It also has performance improvements and other minor features. The protocol, API, and most SQL statements that work with MySQL also fully work with MariaDB. The plugins that are written for MySQL work with MariaDB too. Thanks to these characteristics, most of the applications for MySQL work with MariaDB, without any modifications required. But, at the same time, switching to MariaDB allows one to use interesting features that are not available with MySQL. If an application's developer ignores these features, the application can use the features of both—MariaDB and MySQL. While the reader is probably familiar with DBMS in general, and particularly MariaDB or MySQL, a quick architecture review might be useful. In this introductory chapter, the main components and operations performed by the server are listed. The details are left for discussion in the remaining chapters.

The following schema represents the architecture of MariaDB:

Basically, from a user's point of view, MariaDB receives some SQL queries or statements, elaborates them, and returns a result set. Let's see this process and the components involved in more detail:

When a client connects to MariaDB, an authentication is performed based on the client's hostname, username, and password. Authentication can optionally be delegated to a plugin.

If the login succeeds, the client can send a SQL query to the server.

The parser understands the SQL string.

The server checks whether the client has the permissions required for the requested action.

If the query is stored in the query cache, the results are immediately returned to the client.

The optimizer will try to find the fastest execution strategy, or query plan. This means that the optimizer decides the order in which the tables will be read. It also decides which indexes will be accessed and whether a temporary internal table will be used. A good strategy can greatly reduce the access to the disks and reduce the complexity of the operations by some order of magnitude. This topic will be discussed in Chapter 3, Optimizing Queries.

The storage engines read and write the data and index files and any cache that they may use to speed up operations. Some important features, such as the transactions and foreign keys, are implemented at the storage engine level.

MariaDB and the storage engines maintain a set of logs to keep a track of the received statements, errors occurred, changes to the data, and so on. Most of the logs are optional; however, some logs are necessary for some administrative tasks. For example, the binary log enables backups or replication. Logs will be explained in the later chapters.

MariaDB has several options that affect the server's behavior. Many of them are dynamic, which means that they can be changed at runtime; others are static, which means that the value assigned during a server's startup cannot change. Most of them exist in both—the session level, which means that any individual users can change the value for the current connection, and the global level, which applies to all users who did not set a session value. An option can be specified in several ways, such as server command-line parameters, in configuration files, or if it is dynamic, via a SQL statement. MariaDB reads a set of configuration files in a given order. The exact location and read order are dependent on the operating system. Typically, only one MariaDB instance runs on a machine, so only one configuration file is needed and usually it is /etc/my.cnf on Linux and my.ini in the MariaDB install directory on Windows, for example, C:\MariaDB 10.0\my.ini.

However, this modular configuration system is useful if several MariaDB (and perhaps MySQL) servers are installed on the same machine. Some settings are likely to be valid for all servers, but each server can specify more options or override the generic values. A file can also be placed in a user's home directory, so that it will only be read if MariaDB runs with that identity (the --user start up parameter). The configuration file patch is listed in Chapter 8, Backup and Disaster Recovery. Starting a server with command-line parameters overrides the file's settings. These techniques are useful when testing the behavior of different versions of the server, or with different settings.

This book does not describe all the existing options. The reader should already be familiar with the most important options and server variables. Some of them will, however, be explained when they are relevant to the topics discussed in the book. MariaDB Knowledge Base documents all the existing options.

The MariaDB server is the mysqld file. On Linux, it is possible to run the server directly but it is usually invoked by another script. The mysqld_safe script starts the server and also restarts it in cases where it is terminated abnormally. This is much safer in the production environments. The mysql.server script is also available for the System V-like systems, where the runlevel exists. This script is distributed with another name by many Linux distributions. When several installations are present on the same machine, it is possible to manage them using mysql_multi.

The command-line client

The code and output examples in this book use the mysql command-line client. Knowing some client commands can greatly increase productivity when this tool is used.

The mysql command-line client knows that a SQL statement is terminated when it finds a semicolon (;), a \g, or a \G terminator. In the first case, the output is printed in a tabular form, shown as follows:

MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database          | +--------------------+ | information_schema | | mysql              | | performance_schema | | test              | +--------------------+

Tip

Downloading the example code

You can download the example code files for all Packt Publishing books you have purchased from your account at http://www.packtpub.com. If you have purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

The mysql client has a prompt that normally appears at the beginning of a new line, as follows:

MariaDB [none]>

In the prompt, [none] means that no default database is selected. This means that, every time a table is named in a statement, the name of the database where it is located must be specifically specified. The USE statement selects a default database, whose name will appear in the prompt. The following example shows how to use it:

MariaDB [(none)]> USE test; Database changed MariaDB [test]>

When a statement spans on more lines, the lines begin with a different prompt, as shown in the following example:

MariaDB [test]> SELECT 1     -> FROM DUAL;

If we forget to type a statement terminator, the modified prompt helps us notice the problem, shown as follows:

MariaDB [test]> SHOW TABLES     ->

Here, the mysql client does not know that the statement is finished because a terminator (similar to a semicolon) is missing.

If a quote is open at the end of a line, the quoting character is shown in the prompt of the new line. While one could include a newline character in a string by pressing the Enter key, more often this happens by mistake. As we can see in the following example, the prompt helps us notice the problem:

MariaDB [test]> SELECT 'hello world FROM DUAL;     '>

The problem here is that the end quote for the hello world string is missing. Note that the second line's prompt starts with a single quote.

Sometimes the tabular output is very difficult to read, particularly when output rows are longer than the command-line rows. When this is the case, the \G terminator is more convenient, as shown in the following example:

MariaDB [(none)]> SHOW VARIABLES LIKE 'char%' \G *************************** 1. row *************************** Variable_name: character_set_client         Value: utf8 *************************** 2. row *************************** Variable_name: character_set_connection         Value: utf8 *************************** 3. row *************************** Variable_name: character_set_database         Value: latin1 …

On Linux systems, it is possible to use a pager program to read long outputs. Pagers provide the ability to scroll the output using the keyboard, or the mouse wheel, or any other method supported by the selected pager. Examples