Mariadb

Description

For the single-table syntax, the statement updates
columns of existing rows in the named table with new values. The
clause indicates which columns to modify and the values
they should be given. Each value can be given as an expression, or the keyword
to set a column explicitly to its default value. The
clause, if given, specifies the conditions that identify
which rows to update. With no clause, all rows are
updated. If the ORDER BY clause is specified, the rows are
updated in the order that is specified. The LIMIT clause
places a limit on the number of rows that can be updated.

MariaDB starting with 10.0

The PARTITION clause was introduced in MariaDB 10.0. See Partition Pruning and Selection for details.

Until MariaDB 10.3.2, for the multiple-table syntax, updates rows in each
table named in table_references that satisfy the conditions. In this case,
ORDER BY and LIMIT cannot be used. This restriction was lifted in MariaDB 10.3.2 and both clauses can be used with multiple-table updates. An can also reference tables which are located in different databases; see Identifier Qualifiers for the syntax.

is an expression that evaluates to true for
each row to be updated.

and are as
specified as described in .

Assignments are evaluated in left-to-right order, unless the sql_mode (available from MariaDB 10.3.5) is set, in which case the UPDATE statement evaluates all assignments simultaneously.

You need the privilege only for columns referenced in
an that are actually updated. You need only the
privilege for any columns that are read but
not modified. See .

The statement supports the following modifiers:

  • If you use the keyword, execution of
    the is delayed until no other clients are reading from
    the table. This affects only storage engines that use only table-level
    locking (MyISAM, MEMORY, MERGE). See HIGH_PRIORITY and LOW_PRIORITY clauses for details.
  • If you use the keyword, the update statement does
    not abort even if errors occur during the update. Rows for which
    duplicate-key conflicts occur are not updated. Rows for which columns are
    updated to values that would cause data conversion errors are updated to the
    closest valid values instead.

UPDATE Statements With the Same Source and Target

MariaDB starting with 10.3.2

From MariaDB 10.3.2, UPDATE statements may have the same source and target.

For example, given the following table:

DROP TABLE t1;
CREATE TABLE t1 (c1 INT, c2 INT);
INSERT INTO t1 VALUES (10,10), (20,20);

Until MariaDB 10.3.1, the following UPDATE statement would not work:

UPDATE t1 SET c1=c1+1 WHERE c2=(SELECT MAX(c2) FROM t1);
ERROR 1093 (HY000): Table 't1' is specified twice, 
  both as a target for 'UPDATE' and as a separate source for data

From MariaDB 10.3.2, the statement executes successfully:

UPDATE t1 SET c1=c1+1 WHERE c2=(SELECT MAX(c2) FROM t1);

SELECT * FROM t1;
+------+------+
| c1   | c2   |
+------+------+
|   10 |   10 |
|   21 |   20 |
+------+------+

Starting Multiple MariaDB Server Processes

There are several different methods to start or stop the MariaDB Server process. There are two primary categories that most of these methods fall into: starting the process with the help of a service manager, and starting the process manually. See Starting and Stopping MariaDB for more information.

Service Managers

sysVinit and systemd are the most common Linux service managers. launchd is used in MacOS X. Upstart is a less common service manager.

Systemd

RHEL/CentOS 7 and above, Debian 8 Jessie and above, and Ubuntu 15.04 and above use systemd by default.

For information on how to start and stop multiple MariaDB Server processes on the same server with this service manager, see .

Starting the Server Process Manually

mysqld

is the actual MariaDB Server binary. It can be started manually on its own.

If you want to force each instance to read only a single option file, then you can use the option:

mysqld --defaults-file=/etc/my_instance1.cnf

mysqld_safe

is a wrapper that can be used to start the server process. The script has some built-in safeguards, such as automatically restarting the server process if it dies. See mysqld_safe for more information.

If you want to force each instance to read only a single option file, then you can use the option:

mysqld_safe --defaults-file=/etc/my_instance1.cnf

mysqld_multi

is a wrapper that can be used to start the server process if you plan to run multiple server processes on the same host. See mysqld_multi for more information.

View Tables in Order of Size

Returns a list of all tables in the database, ordered by size:

SELECT table_schema as `DB`, table_name AS `Table`, 
  ROUND(((data_length + index_length) / 1024 / 1024), 2) `Size (MB)` 
  FROM information_schema.TABLES 
  ORDER BY (data_length + index_length) DESC;

+--------------------+---------------------------------------+-----------+
| DB                 | Table                                 | Size (MB) |
+--------------------+---------------------------------------+-----------+
| wordpress          | wp_simple_history_contexts            |      7.05 |
| wordpress          | wp_posts                              |      6.59 |
| wordpress          | wp_simple_history                     |      3.05 |
| wordpress          | wp_comments                           |      2.73 |
| wordpress          | wp_commentmeta                        |      2.47 |
| wordpress          | wp_simple_login_log                   |      2.03 |
...

Examples

CREATE TABLE t1 (d DATETIME);

INSERT INTO t1 VALUES ("2011-03-11"), ("2012-04-19 13:08:22"),
 ("2013-07-18 13:44:22.123456");

SELECT * FROM t1;
+---------------------+
| d                   |
+---------------------+
| 2011-03-11 000000 |
| 2012-04-19 130822 |
| 2013-07-18 134422 |
+---------------------+
CREATE TABLE t2 (d DATETIME(6));

INSERT INTO t2 VALUES ("2011-03-11"), ("2012-04-19 13:08:22"),
 ("2013-07-18 13:44:22.123456");

SELECT * FROM t2;
+----------------------------+
| d                          |
+----------------------------+
| 2011-03-11 000000.000000 |
| 2012-04-19 130822.000000 |
| 2013-07-18 134422.123456 |
+----------------------------++

Strings used in datetime context are automatically converted to datetime(6). If you want to have a datetime without seconds, you should use CONVERT(..,datetime).

SELECT CONVERT('2007-11-30 10:30:19',datetime);
+-----------------------------------------+
| CONVERT('2007-11-30 10:30:19',datetime) |
+-----------------------------------------+
| 2007-11-30 103019                     |
+-----------------------------------------+

SELECT CONVERT('2007-11-30 10:30:19',datetime(6));
+--------------------------------------------+
| CONVERT('2007-11-30 10:30:19',datetime(6)) |
+--------------------------------------------+
| 2007-11-30 103019.000000                 |
+--------------------------------------------+

Getting the Master’s Binary Log Co-ordinates

Now you need prevent any changes to the data while you view the binary log position. You’ll use this to tell the slave at exactly which point it should start replicating from.

  • On the master, flush and lock all tables by running . Keep this session running — exiting it will release the lock.
  • Get the current position in the binary log by running :
SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000096 |      568 |              |                  |
+--------------------+----------+--------------+------------------+
  • Record the File and Position details. If binary logging has just been enabled, these will be blank.
  • Now, with the lock still in place, copy the data from the master to the slave. See Backup, Restore and Import for details on how to do this.
  • Note for live databases: You just need to make a local copy of the data, you don’t need to keep the master locked until the slave has imported the data.
  • Once the data has been copied, you can release the lock on the master by running UNLOCK TABLES.
UNLOCK TABLES;

Configuring Multiple MariaDB Server Processes

If multiple MariaDB Server process are running on the same server, then at minimum, you will need to ensure that the different instances do not use the same , , and . The following example shows these options set in an option file:

# TCP port to use to connect to mysqld server
port=3306
# Socket to use to connect to mysqld server
socket=/tmp/mysql.sock

# TCP port to make available for clients
port=3306
#  Socket to make available for clients
socket=/tmp/mysql.sock
# Where MariaDB should store all its data
datadir=/usr/local/mysql/data

The above values are the defaults. If you would like to run multiple MariaDB Server instances on the same server, then you will need to set unique values for each instance.

There may be additional options that also need to be changed for each instance. Take a look at the full list of options for .

To see the current values set for an instance, see for how to do so.

To list the default values, check the end of:

mysqld --help --verbose

Числовые типы данных

Ниже приведены числовые типы данных в MariaDB:

Синтаксис типа данных Максимальный размер Пояснение
BIT Очень маленькое целочисленное значение, эквивалентное TINYINT(1). Диапазон значений со знаком составляет от -128 до 127. Диапазон значений без знака составляет от 0 до 255.
TINYINT (m) Очень маленькое целочисленное значение. Диапазон значений со знаком составляет от -128 до 127. Диапазон значений без знака составляет от 0 до 255.
SMALLINT (m) Малое целочисленное значение. Диапазон значений со знаком составляет от -32768 до 32767. Диапазон значений без знака составляет от 0 до 65535.
MEDIUMINT (m) Среднее целочисленное значение. Диапазон значений со знаком составляет от -8388608 до 8388607. Диапазон значений без знака составляет от 0 до 16777215.
INT (m) Стандартное целочисленное значение. Диапазон значений со знаком составляет от -2147483648 до 2147483647. Диапазон значений без знака составляет от 0 до 4294967295.
INTEGER (m) Стандартное целочисленное значение. Диапазон значений со знаком составляет от -2147483648 до 2147483647. Диапазон значений без знака составляет от 0 до 4294967295. Это синоним типа данных INT.
BIGINT (m) Большое целочисленное значение. Диапазон значений со знаком от -9223372036854775808 до 9223372036854775807. Диапазон значений без знака от 0 до 18446744073709551615.
DECIMAL (m, d) Неупакованое число с фиксированной точкой.m по умолчанию 10, если не указано.d по умолчанию 0, если не указано. Где m — общее количество цифр, а d — количество цифр после десятичной дроби.
DEC (m, d) Неупакованое число с фиксированной точкой.m по умолчанию 10, если не указано.d по умолчанию 0, если не указано. Где m — общее количество цифр, а d — количество цифр после десятичной дроби.

Это синоним типа данных DECIMAL.

NUMERIC (m, d) Неупакованое число с фиксированной точкой.m по умолчанию 10, если не указано.d по умолчанию 0, если не указано. Где m — общее количество цифр, а d — количество цифр после десятичной дроби. Это синоним типа данных DECIMAL.
FIXED(m, d) Неупакованое число с фиксированной точкой.m по умолчанию 10, если не указано.d по умолчанию 0, если не указано. Где m — общее количество цифр, а d — количество цифр после десятичной дроби. Это синоним типа данных DECIMAL.
FLOAT(m, d) Число с плавающей точкой одинарной точности. Где m — это общее количество цифр, а d — количество цифр после десятичной дроби..
DOUBLE(m, d) Число с плавающей точкой двойной точности. Где m — это общее количество цифр, а d — количество цифр после десятичной дроби..
DOUBLE PRECISION(m, d) Число с плавающей точкой двойной точности. Где m — общее количество цифр, а d — количество цифр после десятичной дроби.

Это синоним типа данных DOUBLE.

REAL(m, d) Число с плавающей точкой двойной точности. Где m — общее количество цифр, а d — количество цифр после десятичной дроби.

Это синоним типа данных DOUBLE.

FLOAT(р) Число с плавающей точкой. Где p — это точность.
BOOL Синоним для TINYINT(1) Рассматривается как логический тип данных, где значение 0 считается FALSE, а любое другое значение считается TRUE.
BOOLEAN Синоним для TINYINT(1) Рассматривается как логический тип данных, где значение 0 считается FALSE, а любое другое значение считается TRUE.

Examples

How to use the ORDER BY and LIMIT clauses:

DELETE FROM page_hit ORDER BY timestamp LIMIT 1000000;

How to use the RETURNING clause:

DELETE FROM t RETURNING f1;
+------+
| f1   |
+------+
|    5 |
|   50 |
|  500 |
+------+ 

The following statement joins two tables: one is only used to satisfy a WHERE condition, but no row is deleted from it; rows from the other table are deleted, instead.

DELETE post FROM blog INNER JOIN post WHERE blog.id = post.blog_id;

Deleting from the Same Source and Target

CREATE TABLE t1 (c1 INT, c2 INT);
DELETE FROM t1 WHERE c1 IN (SELECT b.c1 FROM t1 b WHERE b.c2=);

Until MariaDB 10.3.1, this returned:

ERROR 1093 (HY000): Table 't1' is specified twice, both as a target for 'DELETE' 
  and as a separate source for

From MariaDB 10.3.1:

Query OK,  rows affected (.00 sec)

Other Things

  • All error messages from a slave with a connection name, that are written to the error log, are prefixed with . This makes it easy to see from where an error originated.
  • Errors and now includes connection_name.
  • There is no conflict resolution. The assumption is that there are no conflicts in data between the different masters.
  • All executed commands are stored in the normal binary log (nothing new here).
  • If the server variable > 1 then you will get some information in the log about how the multi-master-info file is updated (mainly for debugging).
  • SHOW SLAVE STATUS has one line per connection and more columns than before. Note that the first column is the !
  • now deletes all relay-log files.

Replication Filters and Binary Log Formats

The way that a replication filter is interpreted can depend on the binary log format.

Statement-Based Logging

When an event is logged in its statement-based format, many replication filters that affect a database will test the filter against the default database (i.e. the one selected by the statement). This applies to the following replication filters:

When an event is logged in its statement-based format, many replication filters that affect a table will test the filter against the table in the default database (i.e. the one selected by the statement). This applies to the following replication filters:

This means that cross-database updates not work with replication filters and statement-based binary logging. For example, if were set, then the following would not replicate with statement-based binary logging:

USE db1;
INSERT INTO db2.tab VALUES (1);

If you need to be able to support cross-database updates with replication filters and statement-based binary logging, then you should use the following replication filters:

Row-Based Logging

When an event is logged in its row-based format, many replication filters that affect a database will test the filter against the database that is actually affected by the event.

Similarly, when an event is logged in its row-based format, many replication filters that affect a table will test the filter against the table in the the database that is actually affected by the event.

This means that cross-database updates work with replication filters and statement-based binary logging.

Keep in mind that DDL statements are always logged to the binary log in statement-based format, even when the system variable is set to . This means that the notes mentioned in always apply to DDL.

Manipulating Weight

There are three fields which can be manipulated: , (the example above uses these two), as well as . To create a backing table with a field as well, the following syntax can be used:

CREATE TABLE oq2_backing (
  origid INT UNSIGNED NOT NULL, 
  destid INT UNSIGNED NOT NULL, 
  weight DOUBLE NOT NULL, 
  PRIMARY KEY (origid, destid), 
  KEY (destid)
);
INSERT INTO oq2_backing(origid, destid, weight)  
 VALUES (1,2,1), (2,3,1), (3,4,3), (4,5,1), (2,6,10), (5,6,2);
CREATE TABLE oq2_graph (
  latch VARCHAR(32) NULL,
  origid BIGINT UNSIGNED NULL,
  destid BIGINT UNSIGNED NULL,
  weight DOUBLE NULL,
  seq BIGINT UNSIGNED NULL,
  linkid BIGINT UNSIGNED NULL,
  KEY (latch, origid, destid) USING HASH,
  KEY (latch, destid, origid) USING HASH
) 
ENGINE=OQGRAPH 
data_table='oq2_backing' origid='origid' destid='destid' weight='weight';
SELECT * FROM oq2_graph;
+-------+--------+--------+--------+------+--------+
| latch | origid | destid | weight | seq  | linkid |
+-------+--------+--------+--------+------+--------+
| NULL  |      1 |      2 |      1 | NULL |   NULL |
| NULL  |      2 |      3 |      1 | NULL |   NULL |
| NULL  |      2 |      6 |     10 | NULL |   NULL |
| NULL  |      3 |      4 |      3 | NULL |   NULL |
| NULL  |      4 |      5 |      1 | NULL |   NULL |
| NULL  |      5 |      6 |      2 | NULL |   NULL |
+-------+--------+--------+--------+------+--------+

Percona XtraDB versions in MariaDB

MariaDB 10.1

  • XtraDB from Percona Server 5.6.46-86.2 in MariaDB 10.1.44
  • XtraDB from Percona Server 5.6.43-84.3 in MariaDB 10.1.39
  • XtraDB from Percona Server 5.6.41-84.1 in MariaDB 10.1.36
  • XtraDB from Percona Server 5.6.38-83.0[] in MariaDB 10.1.31
  • XtraDB from Percona Server 5.6.37-82.2[]in MariaDB 10.1.27
  • XtraDB from Percona Server 5.6.36-82.1 in MariaDB 10.1.26
  • XtraDB from Percona Server 5.6.36-82.0 in MariaDB 10.1.24
  • XtraDB from Percona Server 5.6.35-80.0 in MariaDB 10.1.22
  • XtraDB from Percona Server 5.6.34-79.1 in MariaDB 10.1.20
  • XtraDB from Percona Server 5.6.33-79.0[] in MariaDB 10.1.19
  • XtraDB from Percona Server 5.6.32-78.1 in MariaDB 10.1.18
  • XtraDB from Percona Server 5.6.31-77.0 in MariaDB 10.1.17
  • XtraDB from Percona Server 5.6.30-76.3 in MariaDB 10.1.15
  • XtraDB from Percona Server 5.6.29-76.2 in MariaDB 10.1.14
  • XtraDB from Percona Server 5.6.28-76.1 in MariaDB 10.1.12
  • XtraDB from Percona Server 5.6.26-76.0 in MariaDB 10.1.10
  • XtraDB from Percona Server 5.6.26-74.0 in MariaDB 10.1.8
  • XtraDB from Percona Server 5.6.25-73.1 in MariaDB 10.1.7
  • XtraDB from Percona Server 5.6.24-72.2 in MariaDB 10.1.6
  • XtraDB from Percona Server 5.6.23-72.1 in MariaDB 10.1.5
  • XtraDB from Percona Server 5.6.22-72.0 in MariaDB 10.1.4
  • XtraDB from Percona Server 5.6.21-70.0 in MariaDB 10.1.2
  • XtraDB from Percona Server 5.6.17-65.0 in MariaDB 10.1.1

MariaDB 10.0

  • XtraDB from Percona Server 5.6.42-84.2 in MariaDB 10.0.38
  • XtraDB from Percona Server 5.6.41-84.1 in MariaDB 10.0.37
  • XtraDB from Percona Server 5.6.39-83.1 in MariaDB 10.0.35
  • XtraDB from Percona Server 5.6.38-83.0[]in MariaDB 10.0.34
  • XtraDB from Percona Server 5.6.37-82.2[]in MariaDB 10.0.33
  • XtraDB from Percona Server 5.6.36-82.1 in MariaDB 10.0.32
  • XtraDB from Percona Server 5.6.36-82.0 in MariaDB 10.0.31
  • XtraDB from Percona Server 5.6.35-80.0 in MariaDB 10.0.30
  • XtraDB from Percona Server 5.6.34-79.1 in MariaDB 10.0.29
  • XtraDB from Percona Server 5.6.33-79.0[] in MariaDB 10.0.28
  • XtraDB from Percona Server 5.6.31-77.0 in MariaDB 10.0.27
  • XtraDB from Percona Server 5.6.30-76.3 in MariaDB 10.0.26
  • XtraDB from Percona Server 5.6.29-76.2 in MariaDB 10.0.25
  • XtraDB from Percona Server 5.6.28-76.1 in MariaDB 10.0.24
  • XtraDB from Percona Server 5.6.27-76.0 in MariaDB 10.0.23
  • XtraDB from Percona Server 5.6.26-74.0 in MariaDB 10.0.22
  • XtraDB from Percona Server 5.6.25-73.1 in MariaDB 10.0.21
  • XtraDB from Percona Server 5.6.24-72.2 in MariaDB 10.0.20
  • XtraDB from Percona Server 5.6.23-72.1 in MariaDB 10.0.18
  • XtraDB from Percona Server 5.6.22-72.0 in MariaDB 10.0.17
  • XtraDB from Percona Server 5.6.22-71.0 in MariaDB 10.0.16
  • XtraDB from Percona Server 5.6.21-70.0 in MariaDB 10.0.15
  • XtraDB from Percona Server 5.6.20-68.0 in MariaDB 10.0.14
  • XtraDB from Percona Server 5.6.19-67.0 in MariaDB 10.0.13
  • XtraDB from Percona Server 5.6.17-65.0 in MariaDB 10.0.11
  • XtraDB from Percona Server 5.6.14-rel62.0 in MariaDB 10.0.7

MariaDB 5.5

  • XtraDB from Percona Server 5.5.61-38.13 in MariaDB 5.5.62
  • XtraDB from Percona Server 5.5.59-38.11 in MariaDB 5.5.60
  • XtraDB from Percona Server 5.5.58-38.10 in MariaDB 5.5.59
  • XtraDB from Percona Server 5.5.55-38.9 in MariaDB 5.5.58
  • XtraDB from Percona Server 5.5.55-38.8 in MariaDB 5.5.57
  • XtraDB from Percona Server 5.5.52-38.3 in MariaDB 5.5.53
  • XtraDB from Percona Server 5.5.50-38.0 in MariaDB 5.5.51
  • XtraDB from Percona Server 5.5.49-37.9 in MariaDB 5.5.50
  • XtraDB from Percona Server 5.5.48-37.8 in MariaDB 5.5.49
  • XtraDB from Percona Server 5.5.46-37.7 in MariaDB 5.5.48
  • XtraDB from Percona Server 5.5.46-37.6 in MariaDB 5.5.47
  • XtraDB from Percona Server 5.5.45-37.4 in MariaDB 5.5.46
  • XtraDB from Percona Server 5.5.44-37.3 in MariaDB 5.5.45
  • XtraDB from Percona Server 5.5.42-37.2 in MariaDB 5.5.44
  • XtraDB from Percona Server 5.5.42-37.1 in MariaDB 5.5.43
  • XtraDB from Percona Server 5.5.40-36.1 in MariaDB 5.5.40
  • XtraDB from Percona Server 5.5.38-35.2 in MariaDB 5.5.39
  • XtraDB from Percona Server 5.5.37-35.0 in MariaDB 5.5.38
  • XtraDB from Percona Server 5.5.36-34.0 in MariaDB 5.5.37
  • XtraDB from Percona Server 5.5.35-33.0 in MariaDB 5.5.35
  • XtraDB from Percona Server 5.5.34-32.0 in MariaDB 5.5.34
  • XtraDB from Percona Server 5.5.33-31.1 in MariaDB 5.5.33
  • XtraDB from Percona Server-5.5.32-31.0 in MariaDB 5.5.32

MariaDB 5.1

  • version 5.1.59-13 in MariaDB 5.1.60
  • version 5.1.54-12.5 in
    MariaDB 5.1.55
  • version 5.1.52-11.6 in
    MariaDB 5.2.4 and
    5.1.53
  • version 5.1.49-12 in
    MariaDB 5.1.50
  • version
    in
    MariaDB 5.1.49
  • version 1.0.6-10 in
    MariaDB 5.1.47
  • version 1.0.6-9 in
    MariaDB 5.1.42,
    5.1.44, and
    5.1.44b.
  • version 1.0.4-8 in
    MariaDB 5.1.41 RC
  • version 1.0.3-8 in
    MariaDB 5.1.39 Beta
  • version 1.0.3-6 in
    MariaDB 5.1.38 Beta

Using AUTO_INCREMENT

The AUTO_INCREMENT attribute is used to automatically generate a unique identity for new rows.

CREATE TABLE student_details (
 id INT NOT NULL AUTO_INCREMENT, name CHAR(10), 
 date_of_birth DATE, PRIMARY KEY (id)
);

When inserting, the id field can be omitted, and is automatically created.

INSERT INTO student_details (name,date_of_birth) VALUES 
 ('Chun', '1993-12-31'), 
 ('Esben','1946-01-01'),
 ('Kaolin','1996-07-16'),
 ('Tatiana', '1988-04-13');

SELECT * FROM student_details;
+----+---------+---------------+
| id | name    | date_of_birth |
+----+---------+---------------+
|  1 | Chun    | 1993-12-31    |
|  2 | Esben   | 1946-01-01    |
|  3 | Kaolin  | 1996-07-16    |
|  4 | Tatiana | 1988-04-13    |
+----+---------+---------------+

See AUTO_INCREMENT for more.

MariaDB программирование

  • Алиасы (псевдонимы)
  • Типы данных
  • Литералы
  • Комментарии
  • Объявление переменных
  • Последовательности

MariaDB Триггеры

Создать триггер MariaDB
BEFORE INSERT AFTER INSERT
BEFORE UPDATE AFTER UPDATE
BEFORE DELETE AFTER DELETE
Удалить триггер MariaDB
DROP TRIGGER

MariaDB таблицы и представления

CREATE TABLE Создать таблицу
CREATE TABLE AS Создать таблицу из данных другой таблицы
ALTER TABLE Добавить, изменить, удалить столбцы в таблице; переименовать таблицу
DROP TABLE Удалить таблицу
TRUNCATE TABLE Оператор очистки данных из таблицы
VIEW Виртуальная таблица (представление других таблиц)

MariaDB ключи, индексы и ограничения

Primary Keys Создание, добавление и удаление первичных ключей
Indexes Создание, удаление и переименование индексов (настройка производительности)
Unique Constraints Создание, добавление и удаление уникальных ограничений

MariaDB условия

AND Логический оператор AND
OR Логический оператор OR
AND и OR Логический оператор AND и OR
LIKE Определяет, совпадает ли указанная символьная строка с заданным шаблоном
RLIKE Использует совпадение регулярного выражения в операторе WHERE
IN Определяет, совпадает ли указанное значение с каким-либо значением во вложенным запросе или списке.
NOT Отрицание условия
IS NULL Используется для проверки значения NULL
IS NOT NULL Используется для проверки значения NOT NULL
BETWEEN Определяет диапазон для проверки условия
EXISTS В предложении WHERE внешнего запроса проверяется наличие строк, возвращенных вложенным запросом.

Comparison Operators
Операторы сравнения такие как =, , !=, >,

Резюме

Решения масштабирования различаются в зависимости от потребностей приложения, которое в нем нуждается. Для нас и для большинства веб-приложений я считаю, что репликация (возможно, многомаст.) — это способ перехода с балансировкой нагрузки, распределяющим нагрузку. Облицовка конкретных проблемных областей (огромных таблиц) также необходима для горизонтального масштабирования.

Я также собираюсь сделать снимок Continuent Sequoia и посмотреть, может ли он действительно сделать то, что он promises, поскольку он будет включать в себя наименьшее количество изменений кода приложения.

What You Need to Know

There are no changes in table or index formats between MariaDB 5.5 and MariaDB
10.0, so on most servers the upgrade should be painless.

How to Upgrade

For Windows, see Upgrading MariaDB on Windows instead.

For MariaDB Galera Cluster, see Upgrading from MariaDB Galera Cluster 5.5 to MariaDB Galera Cluster 10.0 instead.

Before you upgrade, it would be best to take a backup of your database. This is always a good idea to do before an upgrade. We would recommend Percona XtraBackup.

The suggested upgrade procedure is:

  1. Modify the repository configuration, so the system’s package manager installs MariaDB 10.0. For example,
    • On Debian, Ubuntu, and other similar Linux distributions, see for more information.
    • On RHEL, CentOS, Fedora, and other similar Linux distributions, see for more information.
    • On SLES, OpenSUSE, and other similar Linux distributions, see for more information.
  2. Set to . It can be changed dynamically with . For example:
  3. Stop MariaDB.
  4. Uninstall the old version of MariaDB.
    • On Debian, Ubuntu, and other similar Linux distributions, execute the following:
    • On RHEL, CentOS, Fedora, and other similar Linux distributions, execute the following:
    • On SLES, OpenSUSE, and other similar Linux distributions, execute the following:
  5. Install the new version of MariaDB.
    • On Debian, Ubuntu, and other similar Linux distributions, see for more information.
    • On RHEL, CentOS, Fedora, and other similar Linux distributions, see for more information.
    • On SLES, OpenSUSE, and other similar Linux distributions, see for more information.
  6. Make any desired changes to configuration options in option files, such as . This includes removing any options that are no longer supported.
  7. Start MariaDB.
  8. Run .
    • does two things:

      1. Ensures that the system tables in the database are fully compatible with the new version.
      2. Does a very quick check of all tables and marks them as compatible with the new version of MariaDB .

Incompatible Changes Between 5.5 and 10.0

As mentioned previously, on most servers upgrading from 5.5 should be painless.
However, there are some things that have changed which could affect an upgrade:

Options That Have Changed Default Values

Most of the following options have increased a bit in value to give better
performance. They should not use much additional memory, but some of them a do
use a bit more disk space.

Option Old default value New default value
(except on 32-bit Windows)
Added

Options That Have Been Removed or Renamed

The following options should be removed or renamed if you use them in your
config files:

Option Reason
Replaced with
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Renamed to
Renamed to
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Renamed to
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB
Removed by XtraDB

Other

The syntax is deprecated in MariaDB 10.0. Use instead.

New Major Features To Consider

You should consider using the following new major features in MariaDB 10.0:

For Master / Slave Setups

  • Global transaction id is enabled by default. This makes it easier to change a slave to a master.
  • MariaDB 10.0 supports parallel applying of queries on slaves. You can enable this with . Note that this works only if your master is MariaDB 10.0 or later.
  • Multi source replication

failover-доступ

Большая часть современного ПО, работающая с MySQL, не может нормально обрабатывать несколько серверов. По этому мы будем использовать haproxy для распределения нагрузки. В этом примере haproxy ставится на каждый сервер, который использует mysql. HAProxy есть в базовом репозитории любого современного дистрибутива, так что просто ставим пакет:

Теперь настраиваем его. Пишем в конфигурацию /etc/haproxy/haproxy.cfg:

Порт 9199 haproxy будет использовать, чтобы убедится, что член кластера работоспособен и функционирует, как нужно. Сам XtraDB кластер не ждет соединений на 9199 порту. Нам потребуется специальный сервис, который будет локально проверять работу xtradb-cluster сервера для HAProxy. Сервис проверки очень прост, это не демон, так что его будет запускать супердемон xinetd. Вернемся на db1. Для начала — установим xinetd:

Создадим там файл /etc/xinetd.d/mysqlchk со следующим содержимым:

Немного подробностей о том, что тут написано. Главные настройки — это server_args. Они позиционные, так что очередность путать нельзя:

  • имя пользователя для проверки. Нужны права CONNECT и REPLICATION CLIENT
  • пароль
  • отвечать, что сервер доступен, если он — донор (то есть остальные сервера в данный момент синхронизируются с него)
  • путь к файлу журнала
  • отвечать, что сервер не доступен, если он сейчас readonly (синхронизируется или заблокирован). Если поставить 1 — haproxy будет считать сервер в статусе readonly доступным
  • путь к my.cnf. В некоторых версиях debian он находится в /etc/mysql/my.cnf

пользователь и пароль в директиве server_args — из конфигурации mysql (выше)

Обратите внимание на путь к my.cnf, в некоторых версиях debian он находится в /etc/mysql/my.cnf. Так же нужно добавить следующую строку в /etc/services:

Так же нужно добавить следующую строку в /etc/services:

После этого можно перезапустить xinetd. Проверим, что сервис проверки работает, как задумано:

Эту последовательность действий надо повторить на всех машинах — членах кластера.

Теперь можно спокойно перезапустить haproxy, зайти на страницу статистики (в данном примере — http://:8086/) и убедится, что haproxy видит все сервера кластера. После этого можно спокойно прописывать на сервере-пользователе БД локальный адрес 127.0.0.1, порт и все остальные настройки — без изменений — и теперь у вас есть отказоустойчивый кластер баз mysql

Архитектура Galera Cluster

Galera предлагает master-master топологию, в которой каждый узел может модифицировать базу данных. Эти изменения отражаются на всех.
В Galera Cluster возможно симулировать поведение «master-slave» топологии, однако это разделение топологий возможно только на уровне приложений: сама база данных использует только топологию «master-master»
В Galera Cluster защита от возможной ситуации «split brain» тривиальна – алгоритм взвешенного опрашивания . Достаточно использовать нечётное число узлов в кластере или назначить каждому узлу его «вес» — число, таким образом, что ни в каком случае не может возникнуть ситуации, что при разделении множества узлов на две части, сумма весов будет в обеих частях будет одинаковой. Если это условие выполняется, в этом случае меньшая часть при рассинхронизации войдёт в состояние в котором запись в таблицу невозможна.
Алгоритм репликации
Репликация в Galera Cluster является синхронной: каждая транзакция на изменение базы данных выполняется параллельно на всех узлах кластера. Таким образом нивелируются риски потери данных и повышается скорость обновления данных.

]

Ко всему прочему, Galera использует несколько техник для того, чтобы уменьшить количество согласований транзакций, состояний гонок и конфликтов данных:

  • Групповая коммуникация. Это абстракция высокого уровня, которая описывает протокол взаимодействия узлов между собой. Этот протокол гарантирует корректность.
  • Множества записи. Таким образом группируются операции записи в некоторое множество записей, избегая ситуаций согласования всеми узлами одиночных записей.
  • Автомат состояний базы данных. Этот автомат обрабатывает транзакции чтения данных внутри локальной базы данных. Имплементация вначале выполняет транзакцию локально на некоторой копии базы данных, а затем передает уже множество всех операций чтения другим узлам для подтверждения и, возможно, получения транзакций обновления состояния.
  • Упорядочивание транзакций. Так, порядок транзакций, перед тем, как их подтвердить локально и передать другим узлам, меняется таким образом, чтобы как можно больше транзакций прошли тест согласования других узлов.

Подробнее об этом можно прочитать в документации Galera Cluster

Ссылка на основную публикацию