domingo, 30 de junho de 2013

MySQL 5.6 no Solaris Usando um Solaris PKG

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-56-on-solaris-using-solaris-pkg.html

O site MySQL.com faz um bom trabalho com a documentação sobre a instalação do MySQL no Solaris. Os hiperlinks podem ser encontradas abaixo.

Crio este post como uma referência e um exemplo de como ele fez bem.
(Eu prefiro o shell bash, mas isso é só comigo ...)

bash-3.2# groupadd mysql
bash-3.2# useradd -g mysql mysql
bash-3.2# pkgadd -d mysql-5.6.12-solaris*.pkg

The following packages are available:
1 mysql MySQL Community Server (GPL)
5.6.12

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: all


Agora você pode fazer uma pequena pausa. Solaris leva um pouco ot processo e instalar aqui.


Processing package instance <mysql> from </export/home/mysql-5.6.12-solaris10*.pkg>

MySQL Community Server (GPL) 5.6.12
Copyright (c) 2000, , Oracle and/or its affiliates. All rights reserved.
Use is subject to license terms.
Using </opt/mysql> as the package base directory.
## Processing package information.
## Processing system information.
1 package pathname is already properly installed.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

This package contains scripts which will be executed with super-user
permission during the process of installing this package.

The selected base directory </opt/mysql> must exist before
installation is attempted.

Do you want this directory created now [y,n,?,q] y
Using </opt/mysql> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

This package contains scripts which will be executed with super-user
permission during the process of installing this package.

Do you want to continue with the installation of <mysql> [y,n,?] y


Installing MySQL Community Server (GPL) as <mysql>
.....


Mais uma vez deixá-lo fazer algum trabalho ...


......2013-06-30 17:40:12 1117 [Note] InnoDB: Starting shutdown...
2013-06-30 17:40:12 1117 [Note] InnoDB: Shutdown completed; log sequence number 1625987

A RANDOM PASSWORD HAS BEEN SET FOR THE MySQL root USER !
You will find that password in '/.mysql_secret'.

You must change that password on your first connect,
no other statement but 'SET PASSWORD' will be accepted.
See the manual for the semantics of the 'password expired' flag.

Also, the account for the anonymous user has been removed.

In addition, you can run:

/opt/mysql/mysql/bin/mysql_secure_installation

which will also give you the option of removing the test database.
This is strongly recommended for production servers.

See the manual for more instructions.

Please report any problems with the /opt/mysql/mysql/bin/mysqlbug script!

The latest information about MySQL is available on the web at

http://www.mysql.com

Support MySQL by buying support/licenses at http://shop.mysql.com

New default config file was created as /opt/mysql/mysql/my.cnf and
will be used by default by the server when you start it.
You may edit this file to change server settings


Installation of <mysql> was successful.


Então, agora, seguindo as instructins por dev.mysql.com

bash-3.2# ln /etc/init.d/mysql /etc/rc3.d/S91mysql
bash-3.2# ln /etc/init.d/mysql /etc/rc0.d/K02mysql


Portanto, agora se eu quiser usar o banco de dados devo ter passado a senha de root que foi criado dinamicamente 1. Eu pessoalmente gosto desse recurso.


# /etc/init.d/mysql start
Starting MySQL
........ SUCCESS!
bash-3.2# ls -al /.mysql_secret
-rw------- 1 root other 96 Jun 30 17:40 /.mysql_secret
# more /.mysql_secret
# The random password set for the root user at Sun Jun 30 17:40:07 2013 (local time): c29IHIZ4


Por isso, vamos entrar e mudar a senha, então estamos prontos para começar. Francamente, você não tem outra escolha.


bash-3.2# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.6.12

Copyright (c) 2000, 2013, 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> show grants for 'root'@'localhost';
ERROR 1820 (HY000): You must SET PASSWORD before executing this statement

mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('somepassword');
Query OK, 0 rows affected (0.04 sec)


E é isso. Estamos agora bem e pronto para ir ...


mysql> exit
Bye
bash-3.2# rm -f /.mysql_secret
bash-3.2# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.6.12 MySQL Community Server (GPL)

Copyright (c) 2000, 2013, 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> SELECT VERSION();
+-----------+
| VERSION() |
+-----------+
| 5.6.12 |
+-----------+
1 row in set (0.00 sec)


Referências | | Links Úteis:

sábado, 15 de junho de 2013

Backup and Recovery for MySQL Script usando innobackup de Percona e Xtrabackup

Original post: http://anothermysqldba.blogspot.com/2013/06/backup-and-recovery-script-for-mysql.html

Então Percona tem a amplamente utilizada ferramenta de backup Xtrabackup e eles percebem que todo mundo costuma usar esta ferramenta em um script de algum tipo. O tem uma página que fala sobre isso: 


Desde que recentemente deu um exemplo de como usar o backup em um anterior cargo . Eu percebi que eu poderia muito bem escrever um script que mostra como roteiro o processo de backup. Além disso, ele tem sido anos desde que eu escrevi em Python, então eu queria ter um pouco de prática também. 

Assim, a introdução do código está abaixo, mas eu coloquei o script no github . 
Ele precisa de mais testes, mas sinta-se livre para verificar o codebase para fora e atualizar e editar. 

Uma vez que o código é testado mais que eu possa atualizar exemplos, mas eu queria ser aberto com esse projeto desde o início. 

Uma vez que é nos primeiros estágios eu recomendo usar o - showcommands = uma opção para que você possa ver o que o código pretende fazer e talvez tente esses comandos.Obviamente, não deve ser utilizado em um sistema de produção ainda. 


Primeiro uma introdução a ela: 

# ./backup_restore.py --help
Usage: backup_restore.py --process=[fullbackup,incremental,prepare,restore] --help --version --showcommands=1

This program enables you to backup full and incremental backups then prepare
and restore them using Percona's Xtrabackup

Options:
--version show program's version number and exit
-h, --help show this help message and exit
--process=PROCESS What would you like to do --process=
[fullbackup,incremental,prepare,restore]
--debug=DEBUG TURN DEBUG ON 1 OR OFF 0 OR VERBOSE 3
--showcommands=SHOWCOMMANDS
Shows the commands instead of executing them except
for the restore section because we go through that
step by step
--backup_root_directory=BACKUP_ROOT_DIRECTORY
THE ROOT DIRECTORY OF ALL YOUR BACKUPS, You can set
DEFAULT at start of the script
--percona_xtrabackup_location=PERCONA_XTRABACKUP_LOCATION
THE LOCATION OF YOUR xtrabackup FILE, You can set
DEFAULT at start of the script
--datadir=DATADIR MYSQL DATA DIR LOCATION, You can set DEFAULT at start
of the script
--username=DB_USERNAME
MySQL Username, You can set DEFAULT at start of the
script
--password=DB_PASSWORD
MySQL Password, You can set DEFAULT at start of the
script
--default_file=DEFAULT_FILE
MySQL my.cnf file location, You can set DEFAULT at
start of the script
--options=PERCONA_OPTIONS
Additional Options for innobackupex 


quinta-feira, 13 de junho de 2013

max_binlog_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/06/maxbinlogcachesize.html

Como você avalia o desempenho do seu banco de dados e estabilidade, é muito provável que você vai começar a rever as suas variáveis. 

Num relance a primeira reação típica para as variáveis ​​abaixo é .. ESPERAR algo está errado minha caixa não tem tanta memória ou até mesmo de espaço em disco para atender a essa MAX limites listados abaixo .... 

MariaDB [(none)]> select @@max_write_lock_count, @@max_binlog_cache_size, @@max_seeks_for_key, @@myisam_max_sort_file_size\G
*************************** 1. row ***************************
@@max_write_lock_count: 4294967295                    -- 4 GB
@@max_binlog_cache_size: 1844674407370954752         --1.6 EB
@@max_seeks_for_key: 429496729                        -- 4 GB
@@myisam_max_sort_file_size: 9223372036853727232       --8 EB 


Você não está sozinho em preocupações com essas variáveis ​​como alguns bugs foram listados sobre essas variáveis ​​ao longo dos anos. Abaixo estão apenas alguns dos alguns mais antigos. 


MySQL atualmente não podem trabalhar com as posições de log binário superiores a 4GB . " 
Tenha em mente que estas são apenas o padrão e as configurações MAX. Você pode ajustá-los para que se sinta mais confortável. 

MariaDB [(none)]> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SELECT @@max_binlog_cache_size;
+-------------------------+
| @@max_binlog_cache_size |
+-------------------------+
| 4294967296 | -- 4GB
+-------------------------+
1 row in set (0.00 sec) 


Por que você gostaria de ... Isso é um assunto completamente diferente. Este é apenas o limite máximo permitido e as operações são separadas em 4GB de qualquer maneira. O valor máximo recomendado é de 4 GB ", para que você possa atualizá-lo, se assim o escolher também. 

Leia mais sobre as suas opções com este na documentação do MySQL: 

quarta-feira, 12 de junho de 2013

MariaDB 10.0.3 Alpha instalação no Fedora 17 x86_64

Original post: http://anothermysqldba.blogspot.com/2013/06/mariadb-1003-alpha-install-on-fedora-17.html

MariaDB 10.0.3 Alpha acaba de ser lançado.
Portanto, para aqueles de vocês que lembro da minha anterior MariaDB 5.5 instalação post, eu decidi ver como ele funciona com 10.0.3.

Eu gosto de algumas das características que estão indo para as MariaDB e Percona lançamentos. Mesmo se você é um grande defensor do MySQL , quando os recursos estão disponíveis nesses lançamentos que não estão sendo portadas para MySQL lançamentos DBAs têm que rever as suas opções e fazer uma escolha.

Assim, a instalação ....

Como eu disse antes do post anterior eu tenho esse software instalado. Então eu vou apenas para uma atualização primeiro.

[root@Fedora64 10]# rpm -qa | grep maria
mariadb-5.5.31-1.fc17.x86_64
mariadb-server-5.5.31-1.fc17.x86_64
mariadb-libs-5.5.31-1.fc17.x86_64
mariadb-bench-5.5.31-1.fc17.x86_64
mariadb-devel-5.5.31-1.fc17.x86_64

Pacotes tão conflituoso no início.

MariaDB-10.0.3-fedora17-x86_64-client.rpm
MariaDB-10.0.3-fedora17-x86_64-common.rpm
MariaDB-10.0.3-fedora17-x86_64-compat.rpm
MariaDB-10.0.3-fedora17-x86_64-connect-engine.rpm
MariaDB-10.0.3-fedora17-x86_64-devel.rpm
MariaDB-10.0.3-fedora17-x86_64-server.rpm
MariaDB-10.0.3-fedora17-x86_64-shared.rpm
MariaDB-10.0.3-fedora17-x86_64-test.rpm

[root@Fedora64 10]# rpm -Uhv *.rpm
warning: MariaDB-10.0.3-fedora17-x86_64-client.rpm: Header V3 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
error: Failed dependencies:
libodbc.so.2()(64bit) is needed by MariaDB-connect-engine-10.0.3-1.x86_64
MySQL-devel conflicts with (installed) mariadb-devel-5.5.31-1.fc17.x86_64  


MariaDB-server-10.0.3-1.x86_64 conflicts with file from package mariadb-server-5.5.31-1.fc17.x86_64
[root@Fedora64 10]#


Portanto, este é apenas um exemplo Virtualbox , para demonstração e avaliação, então eu só removeu tudo o que eu podia e tive que desinstalar. Eu estava esperançoso de que uma atualização iria funcionar, mas este é o código Alpha ainda.
isto é:

[root@Fedora64 10]# rpm -e mariadb mariadb-server mariadb-bench
[root@Fedora64 10]# rpm -e mariadb-libs perl-DBD-MySQL percona-xtrabackup


Portanto, agora que o passado é esvaziado ...

[root@Fedora64 10]# rpm -ihv *.rpm
Preparing... ########################################### [100%]
1:MariaDB-common ########################################### [ 11%]
2:MariaDB-server ########################################### [ 22%]
3:MariaDB-cassandra-engin########################################### [ 33%]
4:MariaDB-client ########################################### [ 44%]
5:MariaDB-devel ########################################### [ 56%]
6:MariaDB-shared ########################################### [ 67%]
7:MariaDB-test ########################################### [ 78%]
8:MariaDB-compat ########################################### [ 89%]
9:galera ########################################### [100%]


Se você se lembrar do passado pós , eu tenho o script init.d desta vez ..

[root@Fedora64 10]# /etc/init.d/mysql start
Starting MySQL..... SUCCESS!
[root@Fedora64 10]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 10.0.3-MariaDB MariaDB Server


Se eles não são terríveis sobre o desempenho, então eu não vejo por que estes não são por padrão:

vi /etc/my.cnf
[mysqld]

userstat=1
# http://www.percona.com/doc/percona-server/5.5/diagnostics/user_stats.html?id=percona-server:features:userstatv2
# https://kb.askmonty.org/en/user-statistics/
feedback=ON
# https://kb.askmonty.org/en/user-feedback-plugin/
MariaDB [(none)]> show variables like '%feedback%';
+--------------------------+------------------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------------------+
| feedback_send_retry_wait | 60 |
| feedback_send_timeout | 60 |
...
| feedback_url | https://mariadb.org/feedback_plugin/post |
| feedback_user_info | |
+--------------------------+------------------------------------------+

MariaDB [(none)]> show variables like '%userstat%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| userstat | ON |
+---------------+-------+



Questões que eu encontrei 30 segundo após a instalação ...:

MariaDB [(none)]> show variables;
ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos


Isso é que é tão longe ... Eu tê-lo instalado e pode rever agora ...

UPDATE: 
Eu enviei isso como um bug . A equipe do MariaDB tem direito de volta para mim e apontou que eu não correr mysql_upgrade e reinicie. Que corrigiu o erro acima. Ainda variáveis ​​se sente como se deve mostrar tudo o que tem, mas isso é uma correção e erro válido da minha parte. Obrigado à equipe MariaDB. 

Para saber mais:

terça-feira, 11 de junho de 2013

MySQL < 5.5 replication to MySQL 5.6

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-55-replication-to-mysql-56.html

Depois de horas de frustração ..... Vou colocá-lo simplesmente como não atualizar para o MySQL 5.6 se você estiver executando qualquer versão menos que o MySQL 5.5.

Você tem que atualizar para o MySQL 5.5 primeiro para manter sua sanidade e dados do tato.

Muita posts e informações estão disponíveis sobre as mudanças de senha no MySQL 5.6 e apoiá-los. Eu mesmo atualizou as senhas do MySQL 5.6 ea caixa estava instalado e funcionando muito bem. O problema estava a replicação. Eu tinha que replicar a partir de uma versão do MySQL inferior a MySQL 5.5 e ele simplesmente não iria funcionar. Eu desativado secure_auth e poderia ligar, mas ainda não tive sorte com a replicação.

Enquanto eu suportar a replicação como um caminho de atualização, o tempo e ficar com MySQL 5.5 em primeiro lugar.

Acabei por fazer o downgrade para MySQL 5.5 e tudo funciona muito bem agora. Se você tem o downgrade sua versão do MySQL que eu tinha que seguir muitas das mesmas medidas que eu fiz na minha Maria diaster cargo para obter a caixa de volta.

domingo, 9 de junho de 2013

Percona Xtrabackup / innobackupex processo de backup e restauração

Original post: http://anothermysqldba.blogspot.com/2013/06/percona-xtrabackupinnobackupex-backup.html

Este é um exemplo muito simples de como usar Percona Xtrabackup / innobackupex 

Este MariaDB só tem o banco de dados mundial em como um exemplo de dados. 
Isso tudo pode ser programado, mas por agora é para fins de demonstração. 

Criar um backup completo: 

MariaDB [(none)]> create database Start_Of_Demo; -- Just here for the demo
Query OK, 1 row affected (0.00 sec)


[root@Fedora64 src]# innobackupex --no-lock --parallel=4 --user=root --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ --no-timestamp /usr/local/src/fullbackup/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/fullbackup'
130609 15:41:39 innobackupex: Connection to database server closed
130609 15:41:39 innobackupex: completed OK!

[root@Fedora64 src]# ls -al fullbackup/
total 18472
drwxr-xr-x. 6 root root 4096 Jun 9 15:41 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:41 backup-my.cnf
-rw-r-----. 1 root root 18874368 Jun 9 15:41 ibdata1
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 world
-rw-r--r--. 1 root root 13 Jun 9 15:41 xtrabackup_binary
-rw-r-----. 1 root root 89 Jun 9 15:41 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:41 xtrabackup_logfile

Criar um backup incremental:

MariaDB [(none)]> create database incremental_1; -- Just here for the demo
Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]#innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental'
130609 15:47:20 innobackupex: Connection to database server closed
130609 15:47:20 innobackupex: completed OK!

[root@Fedora64 src]# ls -al incremental
total 64
drwxr-xr-x. 7 root root 4096 Jun 9 15:47 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:47 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:47 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:47 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 world
-rw-r--r--. 1 root root 13 Jun 9 15:47 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:47 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:47 xtrabackup_logfile 


Crie outro backup incremental:

MariaDB [(none)]> create database incremental_2;-- Just here for the demo
Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]# innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental_2/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental_2'
130609 15:49:49 innobackupex: Connection to database server closed
130609 15:49:49 innobackupex: completed OK!
[root@Fedora64 src]# ls -al incremental_2
total 68
drwxr-xr-x. 8 root root 4096 Jun 9 15:49 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:49 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:49 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:49 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_2
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 world
-rw-r--r--. 1 root root 13 Jun 9 15:49 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:49 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:49 xtrabackup_logfile 


Agora você deve manter isso em mente.
  • Você banco de dados, claro, tem que ser desligado.
    • Se você estiver fazendo uma restauração, é provável que ele caiu de qualquer jeito
  • O diretório de dados deve estar vazio.

Verifique se o servidor está desligado, em seguida, limpar o nosso diretório de dados.

[root@Fedora64 src]# ps -ef | grep mysql
root 4538 1940 0 15:54 pts/2 00:00:00 grep --color=auto mysql

[root@Fedora64 src]# ls -al /var/lib/mysql/
total 28724
drwxr-xr-x. 8 mysql mysql 4096 Jun 9 15:53 .
drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..
-rw-rw----. 1 mysql mysql 16384 Jun 9 15:53 aria_log.00000001
-rw-rw----. 1 mysql mysql 52 Jun 9 15:53 aria_log_control
-rw-r--r--. 1 mysql mysql 18874368 Jun 9 15:53 ibdata1
-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:53 ib_logfile0
-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:17 ib_logfile1
drwx------. 2 mysql mysql 4096 Jun 9 15:43 incremental_1
drwx------. 2 mysql mysql 4096 Jun 9 15:48 incremental_2
drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 mysql
drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 performance_schema
drwx------. 2 mysql mysql 4096 Jun 9 15:40 Start_Of_Demo
drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 world

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

Agora você deve manter isso em mente. Quando você cria seus backups e seguintes backups incrementais, você terá que restaurar o backup completo e depois aplicar todos os backups incrementais. Portanto, não pense que você pode fazer um backup completo de uma tarde apenas restaurar a partir do último backup incremental. Tenha sempre em mente quantos backups incrementais que você pode dar ao luxo de manter diante de outro backup completo é necessária.

Para restaurar apenas o backup completo:

innobackupex --copy-back /usr/local/src/fullbackup/

innobackupex: Starting to copy InnoDB log files
innobackupex: in '/usr/local/src/fullbackup'
innobackupex: back to original InnoDB log directory '/var/lib/mysql'
innobackupex: Finished copying back files.

130609 15:54:57 innobackupex: completed OK!

[root@Fedora64 src]# ls -al /var/lib/mysql/
total 18456
drwxr-xr-x. 6 mysql mysql 4096 Jun 9 15:54 .
drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..
-rw-r--r--. 1 root root 18874368 Jun 9 15:54 ibdata1
drwxr-xr-x. 2 root root 4096 Jun 9 15:54 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:54 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:54 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:54 world


[root@Fedora64 mysql]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 1
Server version: 5.5.31-MariaDB MariaDB Server


Que faz o backup completo, mas eu fiz backups incrementais depois disso. Então ele vai ter que ser desligado eo diretório de dados limpo. Por quê? Você tem que aplicar os backups incrementais para o pleno depois restaurá-lo. É feito como mostra o seguinte exemplo:



innobackupex --apply-log --redo-only /usr/local/src/fullbackup/
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
130609 15:57:59 InnoDB: Starting shutdown...
130609 15:58:00 InnoDB: Shutdown completed; log sequence number 1597964
130609 15:58:00 innobackupex: completed OK!

Agora vamos aplicar o primeiro diretório incremental. Você pode ver no exemplo abaixo que o diretório incremental_1 é agora aplicado no diretório FullBackup. Este não era o caso antes.

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental/
130609 15:58:42 innobackupex: completed OK!
[Root @ Fedora64 src] # ls-al FullBackup /
total de 20.520
drwxr-xr-x. 7 root root 09 de junho de 4096 15:58.
drwxr-xr-x. 6 root root 09 de junho de 4096 15:49 ..
-Rw-r - r -. 1 root root 260 09 de junho 15:41 backup-my.cnf
-Rw-r -----. 1 root root 18874368 09 de junho 15:58 ibdata1
drwxr-xr-x. 2 root root 09 de junho de 4096 15:58 incremental_1
drwxr-xr-x. 2 root root 09 de junho de 4096 15:41 mysql
drwxr-xr-x. 2 root root 09 de junho de 4096 15:41 performance_schema
drwxr-xr-x. 2 root root 09 de junho de 4096 15:41 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 09 de junho mundo 15:41
-Rw-r - r -. 1 root root 13 09 de junho 15:41 xtrabackup_binary
-Rw-r -----. 1 root root 89 09 junho xtrabackup_checkpoints 15:58
-Rw-r -----. 1 root root 2097152 09 de junho 15:58 xtrabackup_logfile

Agora vamos aplicar o segundo diretório incremental. Você pode ver no exemplo abaixo que o diretório incremental_2 é agora aplicado no diretório FullBackup. Este não era o caso antes.
innobackupex --apply-log /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental_2/
innobackupex: Cópia '/ usr/local/src/incremental_2/Start_Of_Demo/db.opt' para '/ usr / local / src / FullBackup / Start_Of_Demo / db.opt'
130609 16:00:09 innobackupex: concluído OK!

[Root @ Fedora64 src] # ls-al FullBackup /
total de 20.524
drwxr-xr-x. 8 root root 4096 09 de junho às 16:00 h.
drwxr-xr-x. 6 root root 09 de junho de 4096 15:49 ..
-Rw-r - r -. 1 root root 260 09 de junho 15:41 backup-my.cnf
-Rw-r -----. 1 root root 18874368 09 de junho 16:00 ibdata1
drwxr-xr-x. 2 root root 09 de junho de 4096 15:58 incremental_1
drwxr-xr-x. 2 root root 09 de junho de 4096 16:00 incremental_2
drwxr-xr-x. 2 root root 09 de junho de 4096 15:41 mysql
drwxr-xr-x. 2 root root 09 de junho de 4096 15:41 performance_schema
drwxr-xr-x. 2 root root 09 de junho de 4096 15:41 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 09 de junho mundo 15:41
-Rw-r - r -. 1 root root 13 09 de junho 15:41 xtrabackup_binary
-Rw-r -----. 1 root root 89 09 de junho 16:00 xtrabackup_checkpoints
-Rw-r -----. 1 root root 2097152 09 de junho 15:58 xtrabackup_logfile


Agora vamos aplicar o diretório de backup completo. Você pode ver no exemplo abaixo que o diretório incremental_2 é agora aplicado no diretório FullBackup. Este não era o caso antes.

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*
[Root @ Fedora64 src] # innobackupex - copy-back / usr / local / src / FullBackup /
[Root @ Fedora64 src] # chown-R mysql: mysql / var / lib / mysql

Tudo agora está restaurado e disponível:

[root@Fedora64 mysql]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 1
Server version: 5.5.31-MariaDB MariaDB Server

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

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
Start_Of_Demo |
incremental_1 |
incremental_2 |
| mysql |
| performance_schema |
world |
+--------------------+

Links disponíveis para referência.

sábado, 8 de junho de 2013

Yum install MariaDB / MySQL desastre, mas fixa

Original post: http://anothermysqldba.blogspot.com/2013/06/yum-install-mariadbmysql-disaster-but.html

Portanto, esta deve ser uma instalação fácil do MariaDB / MySQL. Eu não acho que isso era uma questão de Maria, mas apenas um bug geral. Aqui está o que aconteceu e como eu consertei.

yum MariaDB-servidor de instalação
Então eu adicionei o resto de ter o que você vê abaixo.

[root@Fedora64 log]# rpm -qa | grep maria
mariadb-5.5.31-1.fc17.x86_64
mariadb-server-5.5.31-1.fc17.x86_64
mariadb-libs-5.5.31-1.fc17.x86_64
mariadb-devel-5.5.31-1.fc17.x86_64
Eu pensei que era estranho que eu não recebi um arquivo / etc / init.d / mysql, mas eu fui com ele, eu queria ver o que aconteceu.

[root@Fedora64 log]# mysqld_safe
130608 19:54:36 mysqld_safe Logging to '/var/log/mysqld.log'.
130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130608 19:54:37 InnoDB: The InnoDB memory heap is disabled
130608 19:54:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130608 19:54:37 InnoDB: Compressed tables use zlib 1.2.5
130608 19:54:37 InnoDB: Using Linux native AIO
130608 19:54:37 InnoDB: Initializing buffer pool, size = 128.0M
130608 19:54:37 InnoDB: Completed initialization of buffer pool
130608 19:54:37 InnoDB: highest supported file format is Barracuda.
130608 19:54:38 InnoDB: Waiting for the background threads to start
130608 19:54:39 Percona XtraDB (http://www.percona.com) 5.5.31-MariaDB-30.2 started; log sequence number 1597945
130608 19:54:39 [Note] Plugin 'FEEDBACK' is disabled.
130608 19:54:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130608 19:54:39 [Note] Server socket created on IP: '0.0.0.0'.
130608 19:54:39 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Uau ... A primeira corrida e um fracasso não é um bom sinal. Esta é uma nova instalação diretório mysql deveria ter sido instalado. Então eu comecei com - skip-grant-tables para que eu pudesse entrar na caixa e olhar ao redor.

[root@Fedora64 mysql]# ls -la
total 28700
drwxr-xr-x. 2 mysql mysql 4096 Jun 8 19:58 .
drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..
-rw-rw----. 1 mysql mysql 16384 Jun 8 19:50 aria_log.00000001
-rw-rw----. 1 mysql mysql 52 Jun 8 19:50 aria_log_control
-rw-rw----. 1 mysql mysql 18874368 Jun 8 19:50 ibdata1
-rw-rw----. 1 mysql mysql 5242880 Jun 8 19:58 ib_logfile0
-rw-rw----. 1 mysql mysql 5242880 Jun 8 19:45 ib_logfile1
[root@Fedora64 mysql]#

[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables
130608 20:02:45 mysqld_safe Logging to '/var/log/mysqld.log'.
130608 20:02:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

OK assim que começou ... e faz funcionar, mas ainda um grande problema ainda sem tabela MYSQL!

[root@Fedora64 /]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
information_schema
Phase 3/3: Running 'mysql_fix_privilege_tables'...
ERROR 1049 (42000): Unknown database 'mysql'
FATAL ERROR: Upgrade failed
Isto pode ainda ser fixado ....
[root@Fedora64 /]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 5.5.31-MariaDB MariaDB Server

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

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.01 sec)

MariaDB [(none)]> create database mysql ;
Query OK, 1 row affected (0.13 sec)

MariaDB [(none)]> exit
Bye
OK agora tem uma tabela mysql eu deveria ser capaz de atualizá-lo
[root@Fedora64 /]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
information_schema
mysql
Phase 3/3: Running 'mysql_fix_privilege_tables'...
OK
[root@Fedora64 /]#

OK Então eu parei e comecei a mysqld sem - skip-bolsas, afinal ela acabou de instalar e eu ainda não ter definido uma senha.

[root@Fedora64 mysql]# mysqld_safe
[root@Fedora64 /]# mysql
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)


Ok, então deixe-me tentar de novo ...


[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables

MariaDB [mysql]> show tables;
+---------------------------+
| Tables_in_mysql |
+---------------------------+
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| proxies_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------+
24 rows in set (0.01 sec)

MariaDB [mysql]> select * from user;
Empty set (0.00 sec)

MariaDB [(none)]> create user root ;
Eu não posso usar o seguinte comando porque - skip-grant-tables em ativado.
criar raiz usuário identificado por'';

Então agora eu tenho um usuário root apenas pelo nome, porque tem privilégios de zero.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.00 sec)
Então eu tenho que ir para a caixa novamente com - skip-grant-tables habilitado e atualizar a conta root

UPDATE user
SET Select_priv = 'Y',
Insert_priv='Y',
Update_priv='Y',
Delete_priv='Y',
Create_priv='Y',
Drop_priv='Y',
Reload_priv='Y',
Shutdown_priv='Y',
Process_priv='Y',
File_priv='Y',
Grant_priv='Y',
References_priv='Y',
Index_priv='Y',
Alter_priv='Y',
Show_db_priv='Y',
Super_priv='Y',
Create_tmp_table_priv='Y',
Lock_tables_priv='Y',
Execute_priv='Y',
Repl_slave_priv='Y',
Repl_client_priv='Y',
Create_view_priv='Y',
Show_view_priv='Y',
Create_routine_priv='Y',
Alter_routine_priv='Y',
Create_user_priv='Y',
Event_priv='Y',
Trigger_priv='Y',
Create_tablespace_priv='Y'
WHERE user = 'root';


Agora a reiniciar sem - skip-grant-tables habilitado e estou como root!

[root@Fedora64 /]# ps -ef | grep mysql
root 4522 1513 0 20:26 pts/0 00:00:00 /bin/sh /bin/mysqld_safe
mysql 4650 4522 0 20:27 pts/0 00:00:03 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 8348 3178 0 20:47 pts/1 00:00:00 grep --color=auto mysql
[root@Fedora64 /]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.31-MariaDB MariaDB Server

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

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>


Ufa. Este é mais um exemplo de como corrigi-lo quando as coisas dão errado, mas eu ainda queria o arquivo / etc / init.d / mysql



Tabela dinâmica ou Não Pivot Table

Original post: http://anothermysqldba.blogspot.com/2013/06/piviot-table-or-no-pivot-table.html

Este tópico recentemente surgiu no forums.mysql.com site.

A opinião expressa é que tabelas dinâmicas são muito difíceis de dimensionar e manter valeria a pena um redesenho do esquema, em vez de uma tabela dinâmica. Esta é uma opinião válida com pontos válidos.

Eu gostaria de adicionar o tópico aqui para ajudar a expressar o meu ponto de vista e tê-lo disponível para os outros.

Tudo depende dos dados que estão sendo coletados sobre se você deve usar uma tabela dinâmica ou não. O exemplo dado em um post anterior por mim foi apenas um exemplo de como eles funcionam.

Se você está coletando informações do usuário conhecido (primeiro e último nome, informações de endereço, telefone), então sim uma tabela dinâmica é mais complicado do que o que você precisa. Se você só tem alguns pontos de dados para amarrá-los para fora dessa informação essencial, então sim, outra mesa é uma solução e amarrado com uma junção simples.

O conceito de tabela dinâmica é válida quando é para valores dinâmicos de dados por entidade você está coletando.
Você pode precisar de 10 pontos de dados de 100 usuários. Você pode precisar de 500 pontos de dados sobre os próximos 100 usuários. Pode o esquema manipulá-lo facilmente?

O exemplo dado no post anterior eu concordo não necessita de uma tabela dinâmica. Mas eu usei apenas o conceito que me foi dada no fórum para responder a pergunta.

Idealmente, você pode usar as duas soluções no seu esquema. Pontos de dados centrais, manter-se em colunas. Os dados dinâmicos manter em mesas de articulação.

Se for construído corretamente é muito escalável, os bilhões e bilhões de dados que eu armazenados na tabela dinâmica provou isso para me facilmente. Isso não quer dizer que não iria exigir algum trabalho. Você pode muito bem achar que criar algumas visões ou tabelas resumo que olhar para a tabela dinâmica seria mais fácil para os outros para coletar dados. Isso levanta a questão, então por que não foi os dados armazenados dessa forma, em primeiro lugar? Mais uma vez, depende da natureza dinâmica dos seus dados e aplicativos que usa os dados.

sexta-feira, 7 de junho de 2013

MEMÓRIA e tabelas temporárias

Original post: http://anothermysqldba.blogspot.com/2013/06/memory-and-temporary-tables.html

Desde que eu tenha recebido um pedido de ajuda para responder a perguntas forum.mysql.com com o blog vou continuar a postar alguns exemplos estendidos aqui.

Notei este post: http://forums.mysql.com/read.php?10, 588192,588192 # msg-588192 e eu pensava de uma maneira diferente de lidar com a situação.

Se você precisa de tabelas para lidar com informações temporárias você pode fazê-lo de duas maneiras. Um se for por processamento sessão, então você deve criar apenas uma tabela temporária:

CREATE TEMPORARY TABLE `temporary_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ;


Isto irá resultar em nenhuma frm. E vai embora e fechar a sessão.
Se você precisar dele mais tempo disponível e precisa que ele seja rápido, você pode usar uma tabela MEMORY. Isso vai ficar até que você reiniciar banco de dados, excluir a tabela, etc ..

CREATE TABLE `memory_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MEMORY;


Isso significa que mais uma vez nenhum arquivo. Frm.

Então, se você quer ir limpar as mesas de memória até porque você tem tantos ou algo que você pode encontrar uma lista com o seguinte ...
SELECT TABLE_SCHEMA, ENGINE, COUNT(*) AS count_tables,
SUM(DATA_LENGTH+INDEX_LENGTH) AS size,
SUM(INDEX_LENGTH) AS index_size FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'INFORMATION_SCHEMA')
AND ENGINE = "MEMORY" GROUP BY TABLE_SCHEMA, ENGINE;


Como sempre ... rever as suas necessidades e de referência que funciona melhor para você e para a sua aplicação.