MariaDB replication in general works as follows: on a master server, all updates to the database are written into the binary log as binlog events, a slave server connects to the master and reads the binlog events and applies the events locally to replicate the same changes as done on the master. A server can be both a master and a slave at the same time, it is thus possible for binlog events to replicated through multiple levels of servers.
I ran into an interesting issue today, while examining some EXPLAIN outputs, and wanted to share the findings, as some of this is undocumented.
Basically, you can start with a very simple InnoDB table - 2 INT columns, Primary Key (PK) on the 1st column, regular index on the 2nd:
CREATE TABLE `t1` ( `id1` int(10) unsigned NOT NULL, `id2` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`id1`), KEY `id2` (`id2`) ) ENGINE=InnoDB;
The query is:
SELECT id1 FROM t1;
This is a straight-forward query with no WHERE clause.
Migrating from MySQL to MariaDB is generally a straightforward
procedure: you can shut down MySQL, install MariaDB, and start it
up with a very good chance of success. When
upgrading/crossgrading/migrating from one release of MySQL or
MariaDB to another, it is important to run
mysql_upgrade. The same is true when migrating from
MySQL to MariaDB, in part because MariaDB has some different
definitions for certain privilege tables. This means that the
structures of the MySQL tables are not valid for MariaDB, a
problem easily fixed by mysql_upgrade, unless
you are trying to import an SQL dump from MySQL that creates
tables using the old-style structures and tries to interact with
them before it is possible to run mysql_upgrade.
Let's take a look at why this is a problem and how to solve it.
…
[Read more]MariaDB 10.0.8 was recently released as RC ("Release Candidate"), and is available for download here:
https://downloads.mariadb.org/mariadb/10.0.8/
This is the first RC release of MariaDB 10.0. It is primarily a bug-fix and polishing release, and all features planned for MariaDB 10.0 GA are included in this release.
There were 6 notable changes in MariaDB 10.0.8:
- InnoDB upgraded to version 5.6.14
The first blogpost in this series did a quick introduction to MaxScale, but now it is time start getting our hands dirty. We will get a more practical view on MaxScale and begin to put it to work. The following is based on a simple Proof of Concept that I did recently. The application is a mid-size web-based online shop where scalability is becoming an issue. They use PHP and with an old and rather inflexible framework, so even though changing how the database is used is possible, it's not easy and having database routing in the application code isn't a very good idea either.
As you've heard, MaxScale was recently released, and we'd love for you to try it out and let us know your thoughts.
Anders Karlsson and Ivan Zoratti have written some excellent posts on downloading and setting it up, so if you're intersted in that, please see their respective posts for quick, detailed instructions.
I have spent some time thinking about and working on a project that went public on GitHub at the beginning of this year. That project is called MaxScale and is primarily a proxy server for MySQL/MariaDB databases, although it can be something much more than this. The obvious and often asked question is why do we need another proxy? I want to try to give you a flavor for what MaxScale is and why I think there is a need for a tool like MaxScale.
The architecture of MaxScale makes it different from your average proxy
- MaxScale has awareness of the content it is shipping.
Do you want to learn more about the MariaDB Audit-Plugin? Join Ralf Gebhardt on 5.12.2013 for his live webcast: http://www.skysql.com/why-skysql/webinars/mariadb-audit-plugin-overview
Introduction
Drupal is one of the most popular Content Management Systems (CMS) and is used increasingly in high-visibility sites, such as www.whitehouse.gov. This has brought a lot of attention on how to get the most performance out of Drupal and how to improve the availability of such sites. In this blog series I'll take you through the basics and on through to designing your own HA Drupal site.
But first, we need to understand what the challenges are in getting Drupal (or indeed any CMS) working on multiple servers in such a way as to ensure high availability and performance.
Background: SkySQL is a distributed company. Nearly all of us work from home. To be productive, we need to emulate the best aspects of collaborating as if we were working next to one another. Given that nearly all of us had worked under similar distributed conditions at MySQL AB, we knew what we were getting into when we were founded. Obviously, we wanted to learn from our past experiences when making our choices for tools and processes.