collaborate 2012 - administering mysql for oracle dbas

Administering MySQL for Oracle DBAs

AADMINISTERINGDMINISTERING MMYYSQLSQL FORFOR OORACLERACLE DBADBASS

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 [email protected]_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 [email protected]_schema>show status like 'qc%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | 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 [email protected]>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 [email protected]>create table pru (name varchar(10));Query OK, 0 rows affected (0.19 sec)

mysql [email protected]>insert into pru values ('Jhon'),('Lindenbaumgreen');Query OK, 2 rows affected, 1 warning (0.16 sec)Records: 2 Duplicates: 0 Warnings: 1

mysql [email protected]>show warnings;+---------+------+-------------------------------------------+| Level | Code | Message |+---------+------+-------------------------------------------+| Warning | 1265 | Data truncated for column 'name' at row 2 |+---------+------+-------------------------------------------+1 row in set (0.00 sec)

mysql [email protected]>select * from pru;+------------+| name |+------------+| Jhon || Lindenbaum |+------------+2 rows in set (0.00 sec)

This behavioral can be changed using SQL_MODE modifiers:

Mysql> set SQL_MODE=strict_all_tables; Query OK, 0 rows affected (0.00 sec)

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 [email protected]>set autocommit=off; Query OK, 0 rows affected (0.00 sec)

mysql [email protected]>show variables like '%autocommit%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | OFF | +---------------+-------+ 1 row in set (0.00 sec)

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

10 Session #493


mysql [email protected]>show global variables like 'autocommit%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+ 1 row in set (0.01 sec)

mysql [email protected]>set global autocommit=off; Query OK, 0 rows affected (0.00 sec)

mysql [email protected]>show global variables like 'autocommit%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | 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%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+ 1 row in set (0.00 sec)

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 startWill update MySQL now, if you encounter any problems, please read following file: /usr/share/doc/packages/mysql-community-server/README.SuSELog files inconsistency, please merge following files manually: /var/log/mysql/mysqld.log /var/lib/mysql/mysqld.logRunning protected MySQL...Upgrading MySQL...Looking for 'mysql' as: /usr/bin/mysqlLooking for 'mysqlcheck' as: /usr/bin/mysqlcheckRunning 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/myRunning 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/mySUELDOS.PARAMETROS_REPORTES OK...Running 'mysql_fix_privilege_tables'...OKStarting 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 extended13 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;Query OK, 0 rows affected (0.00 sec) mysql >select count(1) From employees;+----------+| count(1) |+----------+| 10000 |+----------+1 row in set (0.21 sec) mysql >show profiles;+----------+------------+--------------------------------+| Query_ID | Duration | Query |+----------+------------+--------------------------------+| 1 | 0.21665250 | select count(1) From employees |+----------+------------+--------------------------------+1 row in set (0.00 sec)

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 |+----------------------+----------+16 rows in set (0.00 sec)

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 [email protected]_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

mailto:[email protected]_schema

http://www.percona.com/doc/percona-xtrabackup/

http://dev.mysql.com/doc/refman/5.6/en/replication.html

http://dev.mysql.com/doc/

http://www.innodb.com/innodb_plugin/features/

collaborate 2012 - administering mysql for oracle dbas

Technology