Thursday, May 30, 2013

Tamanho por informações Mesa com MySQL

Original post: http://anothermysqldba.blogspot.com/2013/05/size-per-table-information-with-mysql.html


Sabendo o tamanho de seus dados é naturalmente útil. As ferramentas se tornaram mais fáceis ao longo dos anos e diferentes versões do MySQL, mas é algo que você deve verificar, independentemente da sua versão do MySQL.

Se você estiver executando uma versão antiga do MySQL (antes information_schema), então você ainda pode reunir esses dados usando "status da tabela Show e adicione o data_length ao index_length". O information_schema torna isso muito mais fácil, mas você é livre para usá-los sempre que quiser.

Tire proveito do comando pager para reunir apenas as informações que são depois.
[world]> pager egrep -h "Data_length|Index_length"
PAGER set to 'egrep -h "Data_length|Index_length"'
Use o comando SHOW TABLE STATUS para reunir as informações relacionadas:
[world]> show table status like 'City'\G
Data_length: 409600
Index_length: 131072
1 row in set (0.00 sec)
Redefinir o pager:
[world]> pager
Default pager wasn't set, using stdout. 
Tamanho da tabela = data_length + Index_length
[world]> select 409600 + 131072 as Table_Size;
+------------+
| Table_Size |
+------------+
540672 |
+------------+ 

A mesma informação está disponível através do information_schema:

SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE,SUM(DATA_LENGTH+INDEX_LENGTH) AS size,SUM(INDEX_LENGTH) AS index_size
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA IN ('world') AND TABLE_NAME IN ('City') AND ENGINE IS NOT NULL
GROUP BY TABLE_SCHEMA, TABLE_NAME

TABLE_SCHEMA: world
TABLE_NAME: City
ENGINE: InnoDB
size: 540672
index_size: 131072
1 row in set (0.00 sec) 


O ponto, prestar atenção e saber seus dados.

Wednesday, May 29, 2013

MySQL 4.1 - Por favor, atualize

Original post: http://anothermysqldba.blogspot.com/2013/05/mysql-41-please-upgrade.html

A DBA MySQL é frequentemente solicitado para ajudar com várias versões do MySQL. 


SELECT VERSION();
+----------------+
| VERSION() |
+----------------+
| 4.1.18-classic |
+----------------+ 
Mas peço-lhe tudo ... Avaliar suas opções e atualizar.

MySQL tem feito inúmeras questões atualizações de segurança e muito menos atualizações de desempenho. Verifique sua versão do MySQL. Se for qualquer coisa abaixo de 5.5 ou em um grande trecho 5.1.69 faça o upgrade.

Enquanto você pode considerar o seu banco de dados "de trabalho" e disponível para upgrade quando quebra .... Será que vai exigir algum trabalho ... Sim. Será que vai lhe poupar a longo prazo .. Sim. Você vai ter mais do seu sistema ... Sim ...Você poderia tirar proveito de bugs corrigidos ... Sim. Você prefere ser "quebrado" por uma vulnerabilidade de segurança?

Pare e pense por um momento sobre o que você vai dizer para o CEO quando o CEO pergunta por que você se cortou?

Dê uma olhada em seu sistema contra vulnerabilidades de segurança conhecidas:

4.1


Aproveite todas as novas versões disponíveis:

Saturday, May 18, 2013

Usuários do MySQL :: Doações :: mysql_config_editor :: Segurança

Original post: http://anothermysqldba.blogspot.com/2013/05/mysql-users-grants-mysqlconfigeditor.html

Acesso seguro ao banco de dados é provavelmente a prioridade número um para qualquer administrador de banco de dados. Se não for, então você precisa olhar seriamente para porque não é. 

Diretrizes gerais através do manual já estão disponíveis: 


Um dos principais problemas com a segurança em MySQL é, naturalmente, as permissões que dão aos usuários. 
Estas são algumas orientações simples. 

Primeiramente, tenha "super usuário" ou contas de "raiz" a um mínimo. Um usuário com acesso total ou "GRANT ALL" ainda terá acesso quando tiver atingido suas conexões max.Assim, a última coisa que você quer é um programa a ser a execução de comandos com um usuário com acesso completo. 

Tenha em mente que tipos de contas que você está criando. Você pode limitar o usuárioCONSULTAS MAX, atualizações MAX, as conexões MAX e MAX conexões de usuários por hora . 

Tenha em mente que o ambiente de rede, os usuários estão se conectando. Se os usuários estão indo usar endereços de rede DHCP dentro da mesma sub-rede que você seria apenas criar mais trabalho para si mesmo se você limita-los a um único IP. Você ainda pode limitá-los para a sub-rede, embora com um curinga. Por exemplo '192 .168.0.2 "versus '192 .168.0.% ' 

Fique longe de todo o acesso wildcard para o anfitrião e os usuários. 



> CREATE USER ''@'192.168.0.56' ;
Query OK, 0 rows affected (0.02 sec)

> show grants for ''@'192.168.0.56';
+-----------------------------------------+
| Grants for @192.168.0.56 |
+-----------------------------------------+
| GRANT USAGE ON *.* TO ''@'192.168.0.56' |
+-----------------------------------------+


Isto deixá-lo aberto para qualquer pessoa a partir de 192.168.0.56 e não é uma coisa inteligente a fazer seguro. 
Também poderia violar outras contas de 192.168.0.56 porque MySQL verifica anfitrião de primeira e segunda username. 


> GRANT SELECT ON test.* TO 'exampleuser'@'192.168.0.%' IDENTIFIED BY 'somepassword';

> show grants for 'exampleuser'@'192.168.0.%';
+----------------------------------------------------------------------------------------------------------------------+
| Grants for exampleuser@192.168.0.% |
+----------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'exampleuser'@'192.168.0.%' IDENTIFIED BY PASSWORD '*DAABDB4081CCE333168409A6DB119E18D8EAA073' |
| GRANT SELECT ON `test`.* TO 'exampleuser'@'192.168.0.%' |
+----------------------------------------------------------------------------------------------------------------------+

Isso permitirá que seleciona apenas para exampleuser de '192 .168.0.%. Você também deve ter em mente que, se exampleuser está se conectando a partir de locais de acolhimento que o sistema provavelmente localhost usuário antes de o.% Endereço de sub-rede 192.168.0, a menos que o usuário usou o endereço de sub-rede do host para se conectar. 

Isso significa que você pode criar um usuário e senha com diferentes privilégios por host. 


> SHOW GRANTS FOR 'exampleuser'@'localhost';
+--------------------------------------------------------------------------------------------------------------------+
| Grants for exampleuser@localhost |
+--------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'exampleuser'@'localhost' IDENTIFIED BY PASSWORD '*DAABDB4081CCE333168409A6DB119E18D8EAA073' |
| GRANT SELECT, UPDATE, DELETE ON `test`.* TO 'exampleuser'@'localhost' |
+--------------------------------------------------------------------------------------------------------------------+

Tente o seu melhor para não usar o parâmetro - password = opção <senha> via o cliente mysql. Você pode usá-p para solicitar uma senha. 

Você também tem a opção com o MySQL 5.6 para usar o utilitário de configuração do MySQL. 


# mysql_config_editor set --login-path=local --host=localhost --user=root --password
Enter password: 




# mysql_config_editor print --all
[local]
user = root
password = *****
host = localhost 


# Mysql
ERROR 1045 (28000): Acesso negado para o usuário 'root' @ 'localhost' (using password: NO)

# Mysql - login-path = local
Welcome to the MySQL monitor.

# Mysql - login-path = local-e 'SELECT NOW ()';

Você tem opções para nomear diferentes caminhos, como local ou remoto e etc também.Assim, você pode criptografar mais de uma conta de usuário de acesso em seu arquivo ~ mylogin.cnf /. Que é criado uma vez que você usar o comando set. 

Se você tiver scripts shell que utilizam o cliente mysql e, provavelmente, em seguida, ter senhas nos scripts atualizando-os a usar o "- login-path =" é um caminho mais seguro para ir. 


É claro que quando você não precisa mais de um usuário ... Solte o usuário. 


> DROP USER 'exampleuser'@'localhost'; 

Um arquivo ibdata Menor

Original post: http://anothermysqldba.blogspot.com/2013/05/a-smaller-ibdata-file.html

Eu vi o desejo de um arquivo ibdata menor surgir recentemente no forums.mysql.com 

O banco de dados InnoDB usa o arquivo ibdata (s) para armazenar os dados do banco de dados no disco. Configurando seu sistema corretamente é fundamental e você pode aprender mais sobre essas opções aqui: http://dev.mysql.com/doc/refman/5.6/en/innodb-configuration.html 

InnoDB fornece uma transação ACID e mecanismo de armazenamento seguro, é muito produtivo, mas se você estiver apagando e / ou substituição de dados, muitas vezes, você vai precisar para recuperar o espaço perdido ao longo do tempo. Quanto tempo é dependente de seu sistema e uso. Você não pode executar um único comando e recuperar espaço em um arquivo ibdata. Ele vai dar alguns passos e não é um trabalho atrás do cenas, a não ser feito em um servidor escravo. Se você tem um escravo que é melhor para fazer esse trabalho no banco de dados escravo primeiro e depois pretende rodar o servidor de banco de dados para se tornar o banco de dados mestre. 

Assim, duas situações diferentes, estas não são as únicas soluções, mas algumas soluções: 


  • Você quer manter o ibdata apresentar o mesmo tamanho, mas você quer apenas limpar o espaço perdido
A melhor maneira de recuperar o espaço perdido é para despejar os dados e recarregá-lo.Sim, não é a primeira escolha para um DBA eu sei. Isso é mais problemático quanto maior seu banco de dados é. Eu espero que você tenha um banco de dados escravo e pode fazer isso fora do escravo, em seguida, torná-lo um mestre mais tarde. 


  1. Faça backup do banco de dados
    1. mysqldump --user=<username> --password=<> --add-drop-database --master-data=2 --triggers --routines --events --databases (list database names and do not add mysql to this list) > /Just_AN_example/mysqldump_<DATEHERE>_.sql
      1. Isso lhe dá uma cópia ASCII apenas em caso de corrupção binário.
      2. Ela também tem os dados mestre via um comentário, se necessário.
      3. Isto irá manter sua autenticação mysql no tato também.
        1. Gostaria de salvar o banco de dados mysql como depósito separadamente.
    2. Você também pode criar um backup com o MySQL Enterprise Backup ou Percona XtraBackup , se o sistema era um db maior e precisava de backups on-line estas são boas escolhas. Até você, que você usa para várias razões.
  2. Soma de verificação do banco de dados.
    1. Reúna alguns números sobre o que você tem para que você possa compará-lo quando você carregá-lo de volta.
      1. Isto pode ser feito com Percona Toolkit

        1. # ./pt-table-checksum --password=<Password> > checksum_before_dump.txt
      2. A consulta pode escrever-se.
        1. Eu tenho um blog sobre isso também
          1. http://anothermysqldba.blogspot.com/2013/05/mysql-checksum.html
  3. Stop / Start banco de dados e aproveitar este tempo de inatividade para quaisquer variáveis ​​somente leitura você gostaria de ajustar
  4. Carregue o banco de dados back


  1. Siga os passos 1 a 2, no processo acima.
  2. Na etapa 4 do processo acima, você vai querer adicionar o seguinte ao seu arquivo my.cnf.
    1. innodb_file_format = Barracuda
    2. innodb_file_per_table = 1
  3. Remova o arquivo ibdata e logs.
    1. Sem voltar a partir deste ponto
  4. Iniciar a base de dados
  5. Confirmá-lo está instalado e funcionando
  6. Carregue o banco de dados de backup.

Isto, obviamente, seria o melhor a fazer em um servidor não produção / slave para que você possa confirmar todos os passos e obter-se a uma situação viável, em seguida, gire o escravo para ser o novo mestre.

MySQL CHECKSUM

Original post: http://anothermysqldba.blogspot.com/2013/05/mysql-checksum.html

CHECKSUM TABLE é uma informação útil quando você está verificando o status de uma tabela. Isto é frequentemente usado antes e depois de um backup e restauração para garantir que os dados estão intactos. 

Aqui está uma maneira simples de usá-lo via linha de comando MySQL e as ferramentas já disponíveis para você. 



mysql> CREATE USER 'checksumuser'@'localhost';
mysql>GRANT SELECT ON *.* TO 'checksumuser'@'localhost';


mysql>SELECT
CONCAT('mysql --user=checksumuser -e \'CHECKSUM TABLE ',TABLE_SCHEMA,'.',TABLE_NAME ,' EXTENDED\'; ') as cmd_line_query
INTO OUTFILE '/tmp/checksums.sh'
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'INFORMATION_SCHEMA')
AND ENGINE IS NOT NULL
GROUP BY TABLE_SCHEMA, TABLE_NAME;

mysql> exit


# chmod +x /tmp/checksums.sh
# /tmp/checksums.sh > /tmp/checksums_b4dump.sql 

Agora você vai ter todos os seus dados de checksum disponíveis para você no arquivo listado.Um exemplo simples de que os dados abaixo 


Table Checksum
world.City 2011482258
Table Checksum
world.Country 580721939
Table Checksum
world.CountryLanguage 1546017027 


Após o despejo ou processo que está em execução, você pode, então, executar o mesmo script basta alterar o arquivo de saída, em seguida, carregá-lo e comparar os resultados. Ele não é o método mais limpo, mas é uma verificação rápida e fácil para você fazer.

# /tmp/checksums.sh > /tmp/checksums_after_dump.sql


mysql> use test
mysql> CREATE TABLE `checksums` (
`checksums_id` int(11) NOT NULL AUTO_INCREMENT,
table_name varchar(100) DEFAULT NULL,
size_a int(11) DEFAULT NULL,
size_b int(11) DEFAULT NULL,
PRIMARY KEY (`checksums_id`)
) ENGINE=InnoDB ;

LOAD DATA INFILE '/tmp/checksums_b4dump.sql'
IGNORE INTO TABLE checksums
(table_name, size_a);

LOAD DATA INFILE '/tmp/checksums_after_dump.sql'
IGNORE INTO TABLE checksums
(table_name, size_b);

DELETE FROM checksums WHERE table_name = 'Table';

SELECT a.table_name , a.size_a, b.size_b
FROM checksums a
INNER JOIN checksums b ON a.table_name = b.table_name and a.checksums_id != b.checksums_id
WHERE a.size_a IS NOT NULL AND b.size_b IS NOT NULL ;
+-----------------------------------------------------------------------+------------+------------+
| table_name | size_a | size_b |
+-----------------------------------------------------------------------+------------+------------+
| world.City | 2011482258 | 2011482258 |
| world.Country | 580721939 | 580721939 |
| world.CountryLanguage | 1546017027 | 1546017027 |
+-----------------------------------------------------------------------+------------+------------+


#mysql -p
mysql> DROP USER 'checksumuser'@'localhost'; 

NÃO SE ESQUEÇA DE DEIXAR CAIR DO USUÁRIO quando terminar.

Wednesday, May 15, 2013

MySQL contar e selecionar a partir de uma partição

Original post: http://anothermysqldba.blogspot.com/2013/05/mysql-count-and-select-from-partition.html


MySQL Forums tinha uma pergunta sobre como contar linhas por partição.
Achei que seria um bom post no blog também.

Primeiro estes são alguns bons links para ter a revisão partição e pelo menos começar. Os exemplos usados ​​aqui exemplos de referência iniciado com estas páginas.

> CREATE TABLE t2
-> (
-> dt DATE
-> )
-> PARTITION BY RANGE (TO_DAYS(dt))
-> (
-> PARTITION p01 VALUES LESS THAN (TO_DAYS('2007-01-01')),
-> PARTITION p02 VALUES LESS THAN (TO_DAYS('2008-01-01')),
-> PARTITION p03 VALUES LESS THAN (TO_DAYS('2009-01-01')),
-> PARTITION p04 VALUES LESS THAN (MAXVALUE));

> desc t2;
+-------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------+------+-----+---------+-------+
| dt | date | YES | | NULL | |
+-------+------+------+-----+---------+-------+ 

INSERT INTO t2 VALUES ('2007-02-02'),('2008-02-02'),('2009-02-02'),(CURDATE());
Query OK, 4 rows affected (0.04 sec)


OK, então agora podemos selecionar a partir da partição, bem como contar com eles ..

> select count(*) from t2;
+----------+
| count(*) |
+----------+
| 4 |
+----------+ 

> explain partitions select count(*) from t2 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t2
partitions: p01,p02,p03,p04
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 5
Extra: NULL

> SELECT * FROM t2 PARTITION (p02);
+ ------------ +
| Dt |
+ ------------ +
| 2007-02-02 |
+ ------------ +


> SELECT * FROM t2 PARTITION (p04);
+ ------------ +
| Dt |
+ ------------ +
| 2009-02-02 |
| 2013/05/15 |
+ ------------ +

> SELECT * FROM t2 PARTITION (p02, p04);
+ ------------ +
| Dt |
+ ------------ +
| 2007-02-02 |
| 2009-02-02 |
| 2013/05/15 |
+ ------------ +

> Select count (*) from t2 PARTITION (p04);
+ ---------- +
| Count (*) |
+ ---------- +
| 2 |
+ ---------- +


Espero que isso ajude.

Monday, May 13, 2013

Verificando MariaDB 10.0.2

Original post: http://anothermysqldba.blogspot.com/2013/05/checking-out-mariadb-1002.html

Eu baixei o pacote fonte MariaDB 10.0.2 e fiz uma instalação personalizada. Eu fiz isso por causa de um post anterior em que eu tive dois mestres já construídas. Desta vez eu removi a replicação circular e apontou-lhes esta instalação MariaDB. I utilizado porta 3310 neste momento. Mesmos exemplos de configuração de instalação do post anterior se aplica aqui só agora posta em MariaDB-10.0.2 pastas. Eu adicionei a instalação na parte inferior deste post apenas no caso de você quiser. 

A razão pela qual eu fiz isso foi porque eu queria verificar as mais recentes funcionalidades do MariaDB, principalmente, o seguinte: 

Replicação Multi-source 

Certifique-se de que você tem diferentes server-ids definido por servidor para começar. 

Apenas começou então nada aqui deve ser esperado 
> select @@default_master_connection;
+-----------------------------+
| @@default_master_connection |
+-----------------------------+
| |
+-----------------------------+ 

Por isso, reunir informações de um servidor mestre 
> show master status\G
*************************** 1. row ***************************
File: percona_mysql-bin.000005
Position: 107 


Agora atualizar o MariaDB 10.0.2 escravo 
SET @@default_master_connection='percona';

CHANGE MASTER 'percona' TO MASTER_HOST = '127.0.0.1',
MASTER_USER = 'root',
MASTER_PASSWORD = '',
MASTER_PORT = 3307 ,
MASTER_LOG_FILE = 'percona_mysql-bin.000005',
MASTER_LOG_POS = 107 



> select @@default_master_connection;
+-----------------------------+
| @@default_master_connection |
+-----------------------------+
| percona |
+-----------------------------+

Ok, agora deixe-me acrescentar o segundo mestre 
SET @@default_master_connection='oracle';

CHANGE MASTER 'oracle' TO MASTER_HOST = '127.0.0.1',
MASTER_USER = 'root',
MASTER_PASSWORD = '',
MASTER_PORT = 3309 ,
MASTER_LOG_FILE = 'oracle_mysql-bin.000009',
MASTER_LOG_POS = 5453 


Em seguida, você pode verificar o status para assegurar ambas as configurações são criadas. 
>SHOW ALL SLAVES STATUS\G

*************************** 1. row ***************************
Connection_name: oracle
Slave_SQL_State:
Slave_IO_State:
Master_Host: 127.0.0.1
Master_User: root
Master_Port: 3309
Connect_Retry: 60
Master_Log_File: oracle_mysql-bin.000009
Read_Master_Log_Pos: 5453
Relay_Log_File: relay-bin-oracle.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: oracle_mysql-bin.000009
Slave_IO_Running: No
Slave_SQL_Running: No
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 5453
Relay_Log_Space: 248
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: 0
Retried_transactions: 0
Max_relay_log_size: 1073741824
Executed_log_entries: 0
Slave_received_heartbeats: 0
Slave_heartbeat_period: 1800.000
Gtid_Pos:
*************************** 2. row ***************************
Connection_name: percona
Slave_SQL_State:
Slave_IO_State:
Master_Host: 127.0.0.1
Master_User: root
Master_Port: 3307
Connect_Retry: 60
Master_Log_File: percona_mysql-bin.000005
Read_Master_Log_Pos: 107
Relay_Log_File: relay-bin-percona.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: percona_mysql-bin.000005
Slave_IO_Running: No
Slave_SQL_Running: No
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 248
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: 0
Retried_transactions: 0
Max_relay_log_size: 1073741824
Executed_log_entries: 0
Slave_received_heartbeats: 0
Slave_heartbeat_period: 1800.000
Gtid_Pos: 

OK tempo para iniciá-lo 

> START ALL SLAVES;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

root@localhost [(none)]> show warnings;
+-------+------+-------------------------+
| Level | Code | Message |
+-------+------+-------------------------+
| Note | 1937 | SLAVE 'percona' started |
| Note | 1937 | SLAVE 'oracle' started |
+-------+------+-------------------------+ 



Relay_Master_Log_File: percona_mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Relay_Master_Log_File: oracle_mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes


Por isso, vamos testar algumas situações. 

Via Percona mestre 
use test;
CREATE TABLE `multi_test` (
`time_recorded` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB; 

MariaDB Slave 
> show tables;
+----------------+
| Tables_in_test |
+----------------+
| multi_test |
+----------------+ 

Via MySQL mestre da Oracle 
use test;
CREATE TABLE `multi_test2` (
`time_recorded` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB; 

MariaDB Slave 
> show tables;
+----------------+
| Tables_in_test |
+----------------+
| multi_test |
| multi_test2 |
+----------------+ 

OK que funciona! 


MOSTRAR EXPLICAR 
Isto é bastante simples, mas bom para pegar uma consulta, uma vez que está em execução. 
> show explain for 17;
+------+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
| 1 | SIMPLE | sbtest | range | PRIMARY | PRIMARY | 4 | NULL | 99 | Using where |
+------+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
1 row in set, 1 warning (0.00 sec)

root@localhost [test]> show warnings;
+-------+------+----------------------------------------------------------+
| Level | Code | Message |
+-------+------+----------------------------------------------------------+
| Note | 1003 | SELECT SUM(K) from sbtest where id between 4997 and 5096 |
+-------+------+----------------------------------------------------------+ 


Notas laterais: 


Mecanismo de armazenamento Cassandra 
Estou curioso sobre isso e como se relaciona com a solução Innodb via memcache e NoSQL. 
Eu tenho um post sobre isso aqui: http://anothermysqldba.blogspot.com/2013/04/nosql-php-memcache-innodb-mysql.html 

Vou ter que voltar a isso como eu configurar Cassandra no meu ambiente. Eu não sou ansioso, mas curioso. 


Comentários Plugin Usuário 
A documentação do "início rápido", diz a adicionar o arquivo my.cnf em [mysqld] 
[mysqld]
feedback=ON
port = 3310
socket = /tmp/mariadb-10.0.2.sock

130513 17:45:10 InnoDB: 10.0.2-MariaDB started; log sequence number 20183690
130513 17:45:10 [ERROR] /usr/local/mariadb-10.0.2/bin/mysqld: unknown variable 'feedback=ON' 

Isso funcionou muito mais fácil e, como esperar que este caminho uma vez eu removi os "início rápido" instruções. 
> INSTALL PLUGIN feedback SONAME 'feedback.so';

> SELECT plugin_status FROM information_schema.plugins WHERE plugin_name = 'feedback';
+---------------+
| plugin_status |
+---------------+
| ACTIVE |
+---------------+ 


Via log o erro que você também pode vê-lo funcionando: 

[Nota] comentários plugin: relatório 'http://mariadb.org/feedback_plugin/post' foi enviado 
[Nota] comentários plugin: servidor respondeu 'ok' 



No geral minhas atuais melhorias favoritos são: 



A instalação básica foi o seguinte:
# Preconfiguration setup
shell> groupadd mariadb
shell> useradd -r -g mariadb mariadb

# Beginning of source-build specific instructions
shell> tar zxvf MariaDB-VERSION.tar.gz
shell> cd MariaDB-VERSION
shell> cmake .
shell> make
shell> make install DESTDIR="/usr/local/mariadb-10.0.2-tmp"
# End of source-build specific instructions

Build files have been written to: /usr/local/src/MySQL/MariaDB/10.0.2/mariadb-10.0.2

I do not like the results
-- Installing: /usr/local/mariadb-10.0.2-tmp/usr/local/mysql/
If DESTDIR is should install into that location not start with user under that location. This is a MySQL original issue as it does this with all versions of MySQL.

# Fix the odd/bug setup
shell> cd /usr/local/mariadb-10.0.2-tmp
shell> mv usr/local/mysql/ ../mariadb-10.0.2 ;
shell> cd ../; # rm -Rf mariadb-10.0.2-tmp

# Postinstallation setup
shell> cd /usr/local/mariadb-10.0.2
shell> chown -R mariadb .
shell> chgrp -R mariadb .

# Next command is optional
shell> cp support-files/my-small.cnf /etc/mariadb-10.0.2.cnf
shell> vi /etc/mariadb-10.0.2.cnf
port = 3310
socket = /tmp/mariadb-10.0.2.sock

shell> scripts/mysql_install_db --defaults-file=/etc/mariadb-10.0.2.cnf --basedir=/usr/local/mariadb-10.0.2 --skip-name-resolve --datadir=/var/lib/mariadb-10.0.2 --user=mariadb
shell> chown -R mariadb /var/lib/mariadb-10.0.2/*

shell> # bin/mysqld_safe --defaults-file=/etc/mariadb-10.0.2.cnf --user=mariadb --datadir=/var/lib/mariadb-10.0.2/ --port=3310 &


shell> # ./bin/mysql --port=3310 --socket=/tmp/mariadb-10.0.2.sock
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 10.0.2-MariaDB Source distribution

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.