Collaborate 2012 - Administering MySQL for Oracle DBAs

Administering MySQL for Oracle DBAs

ADMINISTERING MYSQL FOR ORACLE DBAS
Eng. Nelson Calero, UYOUG

Oracle Server, the flagship database, has many features familiar to Oracle DBAs for daily
operation of solid production environments. These same DBAs are now expected to manage
Oracle's MySQL that is being adopted by many companies.
We will explore aspects of the full life cycle and tools of a robust commercial MySQL
environment, from development through production, as viewed from an Oracle DBA perspective.
We will cover mandatory changes to vanilla install, explore and differentiate HA solutions, and
look at day to day operation requirements.

INTRODUCTION
MySQL server has a free version, called Community Edition, and several flavors of commercial
versions with more features and support, called Enterprise, Standard, and Cluster Carrier Grade
Edition.

Originally developed to support high volumes of inserts by web applications, it has become
popular for classical transactional workload with the improvements that MySQL has had during
the years, specially the InnoDB engine that now is solid and able to scale well on modern multi-
core hardware.

Being open source (GPL license) has resulted in a big and active user community, which
contributed many improvements over the years, later included in the official distribution.

QUICK OVERVIEW
For a DBA used to working with Oracle databases, it will be easier to start by seeing how MySQL
server implements well know functionalities:
• one server installation handles many databases (which are approximately equivalent to
schemas)
• when the server is running it has two OS processes:
• mysqld, the server
• mysqld_safe, an angel process monitoring msqld health, who restart it when not
running.
• there is no schema concept. A Database owns its objects, and users has grants to use them.
• the server listens on port TCP/IP 3306 by default
• local connections use sockets (similar to BEQ in Oracle)
• uses threads instead of processes. It creates one thread per each client connection
• thread pool, an Oracle shared server like functionality, is a commercial feature of
5.5.16
1 Session #493


• has a cost based optimizer
• has a replication functionality which is not transactional
• has a cluster version, which is another product with a shared nothing architecture

The installation can be done using packages (RPM, .deb) which place its binaries in standard *nix
directories (/usr/bin), or using binary distribution (.tar), which allows us to choose custom
directories. This is the way to go if it is needed to have different versions on the same server.

Different Linux distributions use different standards for placing the files. They are stored in the
locations defined on the startup script (/etc/init.d/mysql in some distributions). Typically they
are:
datadir: /var/lib/mysql
bindir: /usr/bin

All the files handled by the MySQL server instance are inside the datadir directory, unless
changed by the configuration file. There is no OFA-like recommendation to separate the different
files inside the server. But this can be changed easily by parameters in the configuration file
(/etc/my.cnf), allowing us to have our custom directory structure.

INTERNAL COMPONENTS
The MySQL server has a layered architecture which separates the storage handling from the rest
of the database components, like parsing, optimization, SQL and connection handling.
This allows for specific structures and algorithms to handle data, offering different functionality
to the applications, which is called Storage Engines.
One single MySQL server instance can have many active storage engines, and at table level is
defined the one used.
This is a quick review of the internal components inside the server

STORAGE ENGINES
This is a big difference from any other database implementation: a pluggable architecture that
enables different algorithms for handling data, which allows in the same database a different
storage engine per table. These are some of the ones that come with the server:
InnoDB – Transactional. Is the default engine from 5.5
MyISAM – non transactional. Was the default engine before 5.5
Memory – stored only in memory, not persisted to disk
NDB – used by the Cluster
Federated – access tables on remote servers
Archive/Blackhole/Merge – other specific use engines

Also there are third parties implementations. For example the XtraDB from Percona which is an
improved InnoDB. Some more are described and referenced on [3].

2 Session #493


They can be enabled by configuration variables, and with the command SHOW ENGINES the
currently available ones can be seen.
The default version of InnoDB is the plugin implementation (from 5.5), deprecating the older
implementation which used to come with MySQL distribution. It has been rewritten using the
MySQL plugin API, which allows us to extend the server functionality, improving several aspects
and allowing better performance and scalability [1]

Each storage engine takes care of handling data, which is stored in files:
• table.frm – table definition, regardless of storage engine used ($datadir/dbname)
• InnoDB system tablespace – ibdata1
• Stores all data and metadata handled by InnoDB by default
• Can be changed to a external tablespace with the configuration parameter
innodb_file_per_table. When enabled, each table stores its data in one file named table.ibd inside
$datadir/dbname directory.
• other tablespaces – used by NDB similarly as Oracle.

Also, there are files used by the storage engine to handle consistency:
• InnoDB logs – transactional log, used for crash recovery (ib_logfile1) as the Oracle redo logs.
• 2 by default. Circular rotation. No archiving

MEMORY CACHES
There are many caches for specific purposes inside MySQL:
• query cache: for the complete result of a select statement, and shared among sessions. It can
be enabled and configured using several system variables named query_cache_*
• buffer cache: this is handled by the storage engine, so there are many:
InnoDB buffer cache: for data and index blocks
MyISAM key cache: for index blocks
• InnoDB dictionary cache: metadata for opened tables. Also there is the Information_schema
which is global to MySQL and is based on memory tables.
• InnoDB undo log – also called rollback segments, used to undo uncommited transactions
•split in two: an insert and update undo buffer
•part of the system tablespace by default
•since MySQL 5.6 can be moved out with the parameter innodb_undo_tablespaces
• InnoDB log buffer: write buffer for InnoDB log files

BINARY LOGS
All changes done on the server can be written to a file in the order they were executed. This file
can be used to reproduce the changes the server had in a different installation, which is the
foundation for MySQL replication and point in time recovery.
3 Session #493


This is an optional feature which must be enabled using the configuration variable LOG_BIN, and
has also some other considerations: it can filter records by database or table, at the server or
when applying the changes through replication, it can have checksums from 5.6.2, and handles
two formats: statement, row or mixed, which stands for registering the SQL statement executed,
or the complete row data affected by the statement, or a combination of both where the server
decides when it is a better case of using one or the other option. That has to do with the use of
unsafe sentences, which produces different results when executed twice (a DATE function for
example).
The binary log is in a proprietary format but its content can be easily inspected with the
command mysqlbinlog. Also a purge and rotation policy can be configured to be done
automatically with the variables EXPIRE_LOGS_DAYS and MAX_BINLOG_SIZE.
There are many considerations for the proper use and configuration of replication, which can be
found on the documentation [4]

DATA TYPES
There are many data types, which allows for a better and efficient usage of server memory and
storage, covering all needs.
For example, numbers have 9 options, when Oracle only has one: from 1 byte (TINYINT) to 8
(BIGINT), with 2, 3 and 4 options in between, and also SIGNED/UNSIGNED which enables bigger
maximum values, useful for auto increment variables.
As same as Oracle does, the number portion of the int(N) declaration does not affect the storage
used by this datatype, and just limits the output format of it.
Other notable difference is with date datatypes, which has a 3 bytes (DATE), 4 (TIMESTAMP) and
8 (DATETIME) bytes. The difference is that DATE does not stores the time, as the other two do,
and TIMESTAMP is stored in UTC, so timezone conversions are applied when storing and
retrieving data of this type.
Also MySQL allows to use a value of '0000-00-00' as a dummy date, which can be restricted
adding the NO_ZERO_DATE SQL mode.

DATA DICTIONARY
This functionality appeared in version 5.0 of MySQL, with metadata about database objects in the
information_schema database, and the performance_schema database in 5.5.3 with dynamic
metrics about server usage (similar to Oracle v$ views). They both provides a way to automate
administration tasks doing massive operations easy using simple SQL statements.

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema';
+----------------------------------------------+
| TABLE_NAME |
+----------------------------------------------+
| cond_instances |
| events_waits_current |
| events_waits_history |
| events_waits_history_long |
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
4 Session #493


| events_waits_summary_global_by_event_name |
...

Server variables
These variables are similar to Oracle initialization parameters, and allows changing server
functionalities. Some of them can be changed dynamically, but many need to be changed
persistently with startup options or parameter file, because dynamic changes are not stored.
There are two scopes where variables can have different values: at session or global scope.
When changing a variable from a user session, the global scope is not affected in the session
that changed it.

mysql root@localhost.information_schema>show variables like 'query%' limit 4;
+----------------------------------+---------+
| Variable_name | Value |
+----------------------------------+---------+
| query_alloc_block_size | 8192 |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 0 |
+----------------------------------+---------+

Status variables
These are dynamic counters about server activity. There are counters for every activity inside
the server, which are useful for server activity monitoring and performance troubleshooting.

mysql root@localhost.information_schema>show status like 'qc%';
+-------------------------+-------+
+-------------------------+-------+
| Qcache_free_blocks | 0 |
| Qcache_free_memory | 0 |
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 0 |
| Qcache_queries_in_cache | 0 |
+-------------------------+-------+

LOG FILES
There are several internal files generated by server activity, which includes valuable information
to diagnose problems. They are:
• Slow query log: can be enabled to record log running queries which are passed that limit. For
example:
long_query_time=N (0 to 10)

• General log: can be enabled to record all server activity. For example:
general_log = ON

5 Session #493


• Error log: start, stop and error messages generated by the server. The file has the name
hostname.err by default which can be changed with the configuration variable log_error

SECURITY
Internal user security is managed by standard GRANT/REVOKE SQL commands. After a fresh
installation of the server, a command is needed to enable root password security.
Also, access security can be bypassed if the initialization parameter skip-grant-tables is enabled.
The privileges can be defined to allow a combination of user/host to access a specific database,
table and column.
grant select on employees.* to you@'desktop' identified by pwd;

It can be used a wildcard (%) for the hostname, to indicate any host.

The privilege information is internally stored on the database mysql, in the tables user, db,
tables_priv, columns_priv and procs_priv tables. This data can be manipulated directly with SQL
statements also, which has the same effect of the GRANT/REVOKE commands.

Also there exists the possibility to put a limit on the maximum amount of resources used by a
user, with a count limit basis: when the limit is reached, no more activity of that type is allowed.
They are queries, updates and connections per hour, and concurrent users connections, defined
in the WITH parameter of GRANT:

GRANT ALL ON employees.* TO 'you'@'localhost'
WITH MAX_QUERIES_PER_HOUR 20 MAX_UPDATES_PER_HOUR 10
MAX_CONNECTIONS_PER_HOUR 5 MAX_USER_CONNECTIONS 2;

LOCKING AND TRANSACTIONS
The internal locking mechanisms and transaction support is done by the storage engine. The
most popular engines implements row level locking (InnoDB) and table level locking (MyISAM).

Transactions are supported on InnoDB, not by MyISAM.
A special consideration must be taken because autocommit is enabled by default at server level,
which can lead to mistakes because sentences cannot be rolled back even when the storage
engine support it, unless they are included inside a transaction, where autocommit has no effect.
Also, InnoDB has been recently set as the default storage engine, since version 5.5.5.

InnoDB implements multiversion concurrency control being ACID compliance, which is configured
by the isolation level of the TRANSACTION, the initialization parameter transaction-isolation, and
the system variable tx_isolation. The default isolation is REPEATABLE-READ, and there also exists
READ COMMITTED, READ UNCOMMITTED and SERIALIZABLE.
It is important to note that READ-COMMITED does not work with binlog mode STATEMENT.
6 Session #493


What happens if the server crashes? Depends on the storage engine used: InnoDB has auto
recovery (using ib_logfiles), and MyISAM needs manual intervention (myisamchk, repair table)

In addition, some parameters needs to be adjusted if using InnoDB and replication, because data
is flushed per second to disk and it must be ensured that a crash recovery operation does not
rollback transactions already delivered to the binary log to the replication slaves. They are:
• InnoDB_flush_log_at_trx_commit=1: log buffer is written to disk and flushed at commit
• sync_binlog: enables synchronizing the binary log to disk after each write
• innodb_support_xa: enables internal XA coordination between the InnoDB transaction log
and the MySQL binary logs.

COMPARISON WITH ORACLE ARCHITECTURE

Oracle database has many functionalities available at different database edition. Also in the last
years there have appeared new solutions based on software and hardware which provides
different ways to resolve the same tasks. So how can we do a fare comparison with MySQL?
MySQL was Initially created for a specific purpose: faster reads/writes. There are different
implementation decisions in every detail.
For example, if we focus on Oracle architecture which is common to all editions, we can find
many components that are resolved different in MySQL:
• Processes handling
• Optimizer features
• Locking
• Memory management

In addition, many Oracle functionalities are missing in MySQL.

Just to review some specific differences, looking at SQL supported by MySQL:
•No need for dual. Select without FROM clause works.
•Dual exists just for compatibility
•No sequences. autoincrement clause at column definition
•last_insert_id() can show the autoincrement value of last insert
•procedures, but no packages and user defined types
•multi-record insert
•insert delayed
•select into outfile / load data file
•drop table if exists
•partial indexes (column(N)) looks like function based index, but they do not exists.

7 Session #493


Some examples of MySQL functionalities which are not used on Oracle:

CASE INSENSITIVE CHAR COMPARISON

mysql root@localhost.employees>select * from employees where first_name='JAANA' limit 3;
+--------+------------+------------+-----------------+--------+------------+
| emp_no | birth_date | first_name | last_name | gender | hire_date |
+--------+------------+------------+-----------------+--------+------------+
| 52681 | 1956-03-28 | Jaana | Besselaar | M | 1986-09-26 |
| 53990 | 1960-05-26 | Jaana | Cunliffe | M | 1995-07-09 |
| 54450 | 1954-02-24 | Jaana | Ranon | F | 1988-08-23 |
+--------+------------+------------+-----------------+--------+------------+
8 rows in set (0.01 sec)

SILENT CONVERSIONS

mysql root@localhost.employees>create table pru (name varchar(10));
Query OK, 0 rows affected (0.19 sec)

mysql root@localhost.employees>insert into pru values ('Jhon'),('Lindenbaumgreen');
Query OK, 2 rows affected, 1 warning (0.16 sec)
Records: 2 Duplicates: 0 Warnings: 1

mysql root@localhost.employees>show warnings;
+---------+------+-------------------------------------------+
| Level | Code | Message |
+---------+------+-------------------------------------------+
| Warning | 1265 | Data truncated for column 'name' at row 2 |
+---------+------+-------------------------------------------+
1 row in set (0.00 sec)

mysql root@localhost.employees>select * from pru;
+------------+
| name |
+------------+
| Jhon |
| Lindenbaum |
+------------+

This behavioral can be changed using SQL_MODE modifiers:

Mysql> set SQL_MODE=strict_all_tables;

Mysql> insert into pru values ('Jhon'),('Lindenbaumgreen');
ERROR 1406 (22001): Data too long for column 'name' at row 2

NOTE: this works because SET uses SESSION scope by default

8 Session #493


Many other behaviors can be changed to something Oracle-like:

• SQL_MODE=ORACLE
Equivalent to PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS,
NO_TABLE_OPTIONS, NO_FIELD_OPTIONS, NO_AUTO_CREATE_USER.

• SQL_MODE=TRADITIONAL
Equivalent to STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE,
NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER,
and NO_ENGINE_SUBSTITUTION.

Many tools expect the typical SQL_MODE behavior, so this kind of changes must be done
carefully witch proper testing,
An excellent reference for going deeper on this topic is the presentation from Ronald Bradford
"MySQL Idiosyncrasies that BITE" [6]

MYSQL TOOLS
Command line utilities are enough to handle a MySQL installation. These are the commands
needed by almost all server operations:
• mysql: the client console
• mysqladmin: administration tool for mysqld
• mysqldump: logical backup utility
• InnoDB Hot Backup: commercial utility

There are also many third parties solutions created to resolve specific tasks which are a must in
a production environment:
• Percona Toolkit: many useful perl script utilities to monitor and automate a variety of
administration tasks, such as replication management (consistency checks and fixes), server
activity monitor and replicator, among many others
(http://www.percona.com/software/percona-toolkit).
• OpenArk: a collection of scripts, being the most interesting the one for performing a non-
blocking alter table operation (http://code.openark.org/forge/openark-kit)
• Percona XtraBackup: OpenSource non locking transactional backup

There are also many more in the Community Resources page, http://forge.mysql.com/tools/

There exist also many great GUI tools to perform many administrative tasks. One of the most
complete is also an older tool from MySQL which has been improved a lot recently, MySQL
Workbench. This includes many extra functionality besides administration, which comes from
9 Session #493


merging several old tools from MySQL AB: Data modeling, SQL development, database
management, forward and reverse engineering and change management.
It comes also in a Community edition under GPL.

The other great one also comes from MySQL, but this needs a support contract: MySQL
Enterprise Monitor, which is a realtime alerting and monitoring solution.

INSTALLATION AND UPGRADES
Installation is a really simple process, using packaged or binary distributions. For example, to do
a fresh install in Linux:
rpm -Ivh mysql-server

If we are interested on customize the directories used by our installation, it can be done easily
with binary distribution, or changed in the configuration file after initial installation. The default
values used in a single installation, single instance per server are:
/var/lib/mysql – data, binary logs, relay logs, error log
/etc/my.cnf – configuration file
/var/log/mysql/mysqld.log – server log file

We can create and use our own custom deploy, just to not miss OFA:
/u01?
/u02/mysql/data

The default installation has no preset user password for the root user. It should be used the
script mysql_secure_installation to assign an initial one.

On notable consideration is that autocommit is enabled by default, which can be easily changed
using variables or initialization parameters:

mysql root@localhost.employees>set autocommit=off;

mysql root@localhost.employees>show variables like '%autocommit%';
+---------------+-------+
+---------------+-------+
| autocommit | OFF |
+---------------+-------+

If doing a dynamic change like the previous one, do not forget about the existance of GLOBAL
and SESSION variables:

10 Session #493


mysql root@localhost.employees>show global variables like 'autocommit%';
+---------------+-------+
+---------------+-------+
| autocommit | ON |
+---------------+-------+

mysql root@localhost.employees>set global autocommit=off;

mysql root@localhost.employees>show global variables like 'autocommit%';
+---------------+-------+
+---------------+-------+
| autocommit | OFF |
+---------------+-------+

Following this example, it should be remembered that variables are not persistent when changed
with the SET command:

oraculo:/var/lib/mysql # service mysql restart
Restarting service MySQL
Shutting down service MySQL done
Starting service MySQL done

mysql root@localhost.(none)>show global variables like '%autocommit%';
+---------------+-------+
+---------------+-------+
| autocommit | ON |
+---------------+-------+

This needs to be changed through startup options, in my.cnf file, to be persistent.

UPGRADES
That could be as easy as running an upgrade of the package (rpm -Uvh).
Even when this distribution includes a script to do this upgrade, special care needs to be taken
when upgrading to review changes included in the new version, and looking for differences in the
existing version, like:
• new reserved words that could be in use by our existing tables
• parameters in use deprecated/renamed
• data conversion needed for some of our columns?
• known issues

11 Session #493


As usual on any software upgrade procedure, it must be done first on a development
environment to test our system and make sure these changes won't hurt our expected behavior.

This is an example of an upgrade done with RPM -Uvh (minor version) on OpenSuse 11.4:

oraculo:~ # service mysql start
Will update MySQL now, if you encounter any problems, please read following file:
/usr/share/doc/packages/mysql-community-server/README.SuSE
Log files inconsistency, please merge following files manually:
/var/log/mysql/mysqld.log
/var/lib/mysql/mysqld.log
Running protected MySQL...
Upgrading MySQL...
Looking for 'mysql' as: /usr/bin/mysql
Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/my
Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/my
SUELDOS.PARAMETROS_REPORTES OK
...
Running 'mysql_fix_privilege_tables'...
OK
Starting service MySQL done

The new version after the upgrade is:

oraculo:~ # mysql --version
mysql Ver 14.14 Distrib 5.5.21, for Linux (x86_64) using readline 6.1

For example, in the last few months we have seen the following version changes without issues
(although testing is still very important)::
5.5.18-73.1
5.5.18-74.1
5.5.20-75.1
5.5.20-78
5.5.20-80.1
5.5.21-81.1

MYSQL SECURITY & AUDITING

Added to the previously mentioned security management, it must be noted that the privilege ALL
includes SUPER, which allows to administer the MySQL server.
For that, this must be given only when needed, following the least needed principle. Also the use
of the special character % must be avoided whenever possible, using the proper client name:

12 Session #493


GRANT SELECT (col1), INSERT (col1,col2) ON employees.employee TO 'you'@'desk';
GRANT SELECT on employees.* to you@'desk' identified by pwd;
GRANT SELECT on *.* to you@'desk';
GRANT ALL on *.* to you@'%';

Each user/host combination defines a unique user.
It is not possible to block connections to specific users in a Vanilla installation. This is something
that must be resolved outside MySQL.
If it is needed to have proper auditing in place, then Log analysis can be used, but with the
obvious careful that heavily used servers should be avoided, and a replica could be setup for that
specific usage, Also TCP or OS mechanisms can be implemented.

AUDITING
There is not built in functionality for data auditing, but it can be easily implemented using
triggers, the same way as with Oracle. For modification date tracking, the TIMESTAMP datatype
has automatic updating and initialization, so no triggers are needed:

col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

PERFORMANCE MANAGEMENT

Instrumentation is not as deeply developed as in Oracle, so the following tasks cannot be found:
• way of modify/cheat optimizer statistics as in Oracle
• historical repository like AWR – Enterprise Monitor with support contract
• limits on server CPU/IO usages
• ability to rewrite queries on the fly

In the other hand, these are some things that can be done:
• configure many internal memory areas and number of client threads
• use hints to force index usage
• use external home made solution for query rewrite

The classical approach to tackle performance problems starts with the classical unix tools outside
the database: vmstat / oprofile / strace / top.
Something added is the possibility to use the gdb, which is also known as the poor man's profiler
approach. This is something that must be used carefully on production systems, because it can
interfere with the server performance.

To look the activity inside the MySQL database, there are also several sources:
• mytop / innotop utilities
• explain / explain extended
13 Session #493


• before MySQL 5.6.3, subqueries in the FROM clause are executed
• status variables
• com_*, innodb_*, connections
• information_schema
• show engine status / processlist
• profiles

This is an example of enabling SQL profiling to see the internal server activity:

mysql >show profile for query 1;
mysql >set profiling=1;

mysql >select count(1) From employees;
+----------+
| count(1) |
+----------+
| 10000 |
+----------+

mysql >show profiles;
+----------+------------+--------------------------------+
| Query_ID | Duration | Query |
+----------+------------+--------------------------------+
| 1 | 0.21665250 | select count(1) From employees |
+----------+------------+--------------------------------+

mysql >show profile for query 1;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000142 |
| checking permissions | 0.000017 |
| Opening tables | 0.140542 |
| System lock | 0.000039 |
| init | 0.000022 |
| optimizing | 0.000008 |
| statistics | 0.000011 |
| preparing | 0.000009 |
| executing | 0.000005 |
| Sending data | 0.075795 |
| end | 0.000018 |
| query end | 0.000007 |
| closing tables | 0.000012 |
| freeing items | 0.000020 |
| logging slow query | 0.000003 |
| cleaning up | 0.000005 |
+----------------------+----------+

14 Session #493


BACKUP & RECOVERY

Included on the standard distribution is the mysqldump utility, which takes logical backups and is
engine independent. It can also be used to do partial backups, of a single table, a complete
database or the entire instance (server).
It can be used while the server is running (hot backup) and different locking strategies are used
based on storage engine to maintain consistency. The option –single-transaction with a
transactional engine like InnoDB does not lock tables and guarantees consistency, but has some
restriction: DDL cannot be done over the tables involved.
Recovery using these backups is as easy as running them (they are a SQL file).

For physical backups, historically existed the licensed tool innodbhotbackup. But a few years ago
Percona developed XtraBackup, an open-source hot backup / non-locking tool for InnoDB and
XtraDB (Percona's own storage engine). It is simple to use and is very well documented. To
recover, an extra step is needed to prepare the files, which apply the changes generated while
the backup was running. After this, backup files are ready to be opened by MySQL server, so
they only need to be copied to the data directory to be used. [6]

With the MySQL Commercial Edition there is the Enterprise Backup utility, which includes the
older innodbhotbackup.

The Cluster version come with its own native backup implementation, which runs inside its
management client, ndb_mgm. There it can be run and monitored. Each node generates three
files, for the metadata, node data and transaction log. To restore this backup, it must be used
the tool ndb_restore. Logical backups can also be taken, with mysqldump.

DESIGNING FOR HIGH AVAILABILITY

There are many possibilities to create a high availability solution with MySQL, some with native
functionalities, and some with third parties solutions.
The challenge is to meet the HA requirements restricted to the time frame available to train the
people involved on the chosen solution operation, because all requires some kind of manual
intervention, which needs to be done carefully.

The most popular and simple initial solution is the built in replication, which have some well
know drawbacks, but it is useful for several use cases. It is based on the transfer and apply of
the binary logs from the master to slaves, and is really simple to setup (in the order of minutes).
It is flexible to create cascade configurations, can be partial, filtering by DB, tables, and
combined. It is asynchronous, and Semi-sync from 5.5.
The biggest drawback is that it is easy to break, and because of that it needs periodical
consistency checks. It also does not have a conflict resolution mechanism, and needs manual
intervention when detected.

15 Session #493


Also there is not automated failover in case of failures on the master server, and the apply is
single threaded until 5.6.
To scale on writes, it can be configured as circular, but it needs application level coding to avoid
inconsistencies.

The other native solution is the MySQL Cluster. This is a different distribution and binaries from
version MySQL 5.5. It has a shared nothing architecture, composed of Data nodes, SQL nodes
and a Manager. Data is stored redundant among Data nodes, and support online operations:
backup, upgrade, node provisioning
The Memory usage is tied to the data handled and #nodes in the cluster.
Version 7.2 is the most recent production and has many improvements.

Other solutions from third parties are:
• SAN/DRBD: Protection from server failures creating a disk based replication on the OS.
• Pacemaker: Cluster resource manager. Automation of HA among servers.
• Galera: Synchronous replication as server plugin. Community and Enterprise.
• Tungsten: MultiMaster replication at application level. Community and Enterprise.

CONCLUSION

MySQL addresses the same problems as Oracle Databases. Originally created to be a fast
alternative for specific usages, it has been improved over the years and been adopted by many
big internet companies, which have contributed to make it a robust solution as it is now. With a
good functionality set and great performance on modern hardware, also supported by a big
community of users which are constantly adding improvements.
Oracle has so many functionalities, that trying to compare just that ends with obvious answer.
Proper evaluation based on each system needs has to be done. Also, some great functionality
could be found in MySQL which is not present in the cheaper Oracle Database editions, as
Partitioning for example.
Monitoring and administrative tasks in the Community edition are something that can be
resolved with custom scripts using standard OS tools or third party FOSS solutions. The
Commercial edition of MySQL includes a tool which automates this.
When facing problems, being FOSS software its source code is available. This allows to overcome
lack of specialized tools for specific issues, and depending on your skills you can fix your
own problems, and benefit the community.

TIP: BETTER COMMAND LINE PROMPT
Command line could be tuned similarly as sqlplus with glogin script?

oracle@oraculo:~> sqlplus / as sysdba
16 Session #493


SQL*Plus: Release 11.2.0.2.0 Production on Tue Feb 28 22:09:00 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

22:09:01 SYS@XE>

oracle@oraculo:~> tail $ORACLE_HOME/sqlplus/admin/glogin.sql
set pagesize 200
set linesize 120
SET TIME ON TIMING ON
SET SQLPROMPT '&_user@&_connect_identifier>'

Add PROMPT parameter to /etc/my.cnf
[mysql]
no-auto-rehash
prompt=mysql u@h.d>

oraculo:~ # mysql
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 7
Server version: 5.5.21-log Source distribution
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql root@localhost.(none)>use information_schema
Database changed

mysql root@localhost.information_schema>

REFERENCES
[1] http://www.innodb.com/innodb_plugin/features/
[2] http://dev.mysql.com/doc/
[3] http://forge.mysql.com/projects/search.php?t=tag&k=storage%20engine
[4] http://dev.mysql.com/doc/refman/5.6/en/replication.html
[5] http://ronaldbradford.com/blog/mysql-idiosyncrasies-that-bite-2010-06-28/
[6] http:// www.percona.com/doc/percona-xtrabackup/

17 Session #493

Collaborate 2012 - Administering MySQL for Oracle DBAs

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (8)

Similar to Collaborate 2012 - Administering MySQL for Oracle DBAs

Similar to Collaborate 2012 - Administering MySQL for Oracle DBAs (20)

More from Nelson Calero

More from Nelson Calero (20)

Recently uploaded

Recently uploaded (20)

Collaborate 2012 - Administering MySQL for Oracle DBAs