terça-feira, 24 de setembro de 2013

MySQL uma comunidade global

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-global-community.html

Sinto-me encorajado pela resposta a este blog para agradecer a todos que leram.

Desde o MySQL é uma comunidade global. Eu percebi que eu gostaria de salientar o interesse global que eu tenho rastreado através deste blog. Isso de maneira nenhuma pode determinar o único interesse em MySQL global por região. No entanto, eu achei interessante ver os diferentes temas que os diferentes países / idiomas estão focados. Os temas realmente variam. Talvez você também pode encontrar algo útil e talvez ele possa ajudar mais apoio direto à comunidade não-Inglês.

Eu não vou quebrá-lo pelo país, mas não por linguagem para refletir os diferentes blogs.

English:






Chinese:




Japanese:





Spanish:




Portuguese:







MySQL YUM Repo (da Oracle, MariaDB e Percona)

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-yum-repo-oracles-mariadb-and.html

Muitas pessoas hoje preferem ficar com o gerenciador de pacotes yum para instalar seu software relacionado sobre o download do último RPM do MySQL, por exemplo.

Enquanto você pode baixar RPMS de um fornecedor e instalar com o yum (yum install *. Rpm) também poderá atualizar o seu repositório yum para puxar diretamente do fornecedor para os pacotes do MySQL. No momento deste post, você só vai deixá-lo pronto para o MySQL 5.5.13, embora MySQL 5.6 GA foi lançado 05 fevereiro de 2013 , através do Oráculo de recompra. Agora que MariaDB lançou MariaDB 5.5.33-Espero que a Oracle vai começar a se mexer e atualizar seu repo público.

Independentemente do que você escolher. Aqui está como configurar repos fornecedores para que você possa acessar o que você gostaria.

Todos os casos têm páginas que eu listei, que são fáceis de seguir e configurar. Eu vou seguir em frente e dar exemplos bem.

Vou usar CentOS 6 64bits para estes exemplos.

Em todos os casos, você estará trabalhando a partir do diretório yum.repos.d como root.
cd / etc / yum.repos.d


http://public-yum.oracle.com
wget https://public-yum.oracle.com/public-yum-ol6.repo
# Vi público-yum-ol6.repo
Localize a seguinte e editar habilitado a 1 de 0 salve o arquivo.




[Ol6_MySQL]
name = MySQL para Oracle Linux 6 ($ basearch)
baseurl = http://public-yum.oracle.com/repo/OracleLinux/OL6/MySQL/ $ basearch /
gpgkey = file :/ / / etc / PKI / rpm-gpg / RPM-GPG-KEY-oracle
gpgcheck = 1
enabled = 1

yum list | grep MySQL
mysql.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs-compat.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-server.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-test.x86_64 5.5.34-1.el6 ol6_MySQL


https://downloads.mariadb.org/mariadb/repositories/
vi MariaDB.repo






MariaDB não oferecer-lhe a opção de escolher 5.5 ou 10, eu usei 5.5 para este exemplo.


# MariaDB 5.5 CentOS repository list - created 2013-09-24 21:59 UTC
# http://mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1



MariaDB-Galera-server.x86_64 5.5.32-1 mariadb
MariaDB-client.x86_64 5.5.33a-1 mariadb
MariaDB-common.x86_64 5.5.33a-1 mariadb
MariaDB-compat.x86_64 5.5.33a-1 mariadb
MariaDB-devel.x86_64 5.5.33a-1 mariadb
MariaDB-server.x86_64 5.5.33a-1 mariadb
MariaDB-shared.x86_64 5.5.33a-1 mariadb
MariaDB-test.x86_64 5.5.33a-1 mariadb
galera.x86_64 23.2.6-1.rhel6 mariadb



http://www.percona.com/doc/percona-server/5.5/installation/yum_repo.html
vi Percona.repo

[percona]
name = CentOS $releasever - Percona
baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona
gpgcheck = 1


percona-toolkit.noarch 2.2.4-1 @/percona-toolkit-2.2.4-1.noarch
percona-xtrabackup.x86_64 2.1.3-608.rhel6 @/percona-xtrabackup-2.1.3-608.rhel6.x86_64
Percona-SQL-50-debuginfo.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-client-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-devel-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-server-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-compat.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-test-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-Server-51-debuginfo.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-55-debuginfo.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-56-debuginfo.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-client-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-client-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-client-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-devel-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-devel-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-devel-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-server-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-server-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-server-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-shared-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-compat.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-compat-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-test-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-XtraDB-Cluster-client.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-debuginfo.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-devel.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-galera.x86_64 2.7-1.157.rhel6 percona
2.7-1.157.rhel6 percona
Percona-XtraDB-Cluster-server.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-shared.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-test.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
jemalloc.x86_64 3.3.1-1.el6 percona
jemalloc-devel.x86_64 3.3.1-1.el6 percona
percona-cacti-templates.noarch 1.0.4-1 percona
percona-nagios-plugins.noarch 1.0.4-1 percona
percona-playback.x86_64 0.6-2.el6 percona
percona-playback-debuginfo.x86_64 0.6-2.el6 percona
percona-playback-devel.x86_64 0.6-2.el6 percona
percona-xtrabackup.x86_64 2.1.5-680.rhel6 percona
percona-xtrabackup-20.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-debuginfo.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-test.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-test.x86_64 2.1.5-680.rhel6 percona
qpress.x86_64 11-1.el6 percona
qpress-debuginfo.x86_64 11-1.el6 percona

 
Esperemos que isto irá ajudá-lo a ser capazes de ficar atualizado além do que poderia estar em seus repositórios padrão no momento.

segunda-feira, 23 de setembro de 2013

ERRO 1146 (42S02): Quadro não existe

Original post: http://anothermysqldba.blogspot.com/2013/09/error-1146-42s02-table-doesnt-exist.html

Então, alguns de vocês podem ter executado através dos seguintes erros ao instalar o MySQL 5.6:
  • ERROR 1146 (42S02): não existe 'mysql.innodb_index_stats «Quadro
  • ERROR 1146 (42S02): não existe 'mysql.innodb_table_stats «Quadro
  • ERROR 1146 (42S02): Table 'mysql.slave_master_info' não existe
  • ERROR 1146 (42S02): Table 'mysql.slave_relay_log_info' não existe
  • ERROR 1146 (42S02): Table 'mysql.slave_worker_info' não existe
Você provavelmente espantado que você vê esse erro em uma instalação de banco de dados fresco. Você não está sozinho. A questão é corrigível embora.

A coisa mais segura a fazer é reinstalar o banco de dados mysql através do seguinte comando: mysql_install_db
Recentemente, tive que fazer isso em cada nova instalação (sim, isso aconteceu mais de uma vez) do MySQL 5.6 em um ambiente Solaris Sparc.

Você pode tentar usar o seguinte para criar as tabelas em falta, mas eu achei melhor manter tudo limpo e garantir tudo está configurado com o mysql_install_db.
Alguns fazem recomendar a correção launchpad que eu mencionei acima, mas eu gosto Eu disse que prefiro o mysql_install_db para garantir que tudo está ligado corretamente instalado.

Tenho outros posts que incluem exemplos de como usar este comando:

Related posts sobre este tema:
Se você se depara com isso a partir de tabelas fora do escopo mysql_install_db ver post no blog de Pedro para ajudar você a começar:

terça-feira, 10 de setembro de 2013

mysqld_multi

Original post: http://anothermysqldba.blogspot.com/2013/09/mysqldmulti.html

Então, eu estava recentemente trabalhando com mysqld_multi e eu percebi que isso era uma característica que eu não vejo em muitos posts esses dias. Eles existem e eu listei alguns no final deste post para sua referência.

Suas razões são susceptíveis de variar e também ser discutível quando se trata do conceito de: deve executar mais de uma instância MySQL no mesmo hardware.

Para evitar qualquer confusão, se você quiser instalar outra instância MySQL para fins de teste e não como uma instância de produção, então você deve apenas trabalhar com MySQL Sandbox . Se isso, por algum motivo isso não funcionar, você pode executar outro servidor como muitas pessoas costumam fazer: criar novos arquivos my.cnf e inicie o servidor MySQL com o mysqld_safe e comandos personalizados.

Mysqld_multi torna muito mais fácil para você executar diversos servidores.

Por exemplo:
Você tem um servidor secundário em execução na porta 3306. É um read_only escravo e você tem um monte de hardware no lugar esperando para se tornar o novo servidor primário quando a corrente primária falhar. Você também gostaria de aproveitar a Percona kit de ferramentas e ter um servidor secundário replicado que está sendo executado em um modo atrasado. Se você pode atualizar para o MySQL 5.6 , então você não precisaria pt-slave-delay , mas atualmente isso não é uma opção.

Em ambos os casos, você tem limites orçamentários e não são permitidos outro servidor. Então você desistir? Você tem o espaço em disco para armazenar outra versão do servidor em sua caixa de secundária por que não? A idéia de ter que iniciar e parar versões personalizadas e etc pode ser fora da colocação de alguns. Então, em vez disso você pode configurar uma nova versão do arquivo my.cnf, mas primeiro você pode fazer o seguinte.

Escolha o seu editor favorito (ou seja: vi)
vi /etc/multi_my.cnf
[mysqld_multi]
mysqld = /usr/local/bin/mysqld_safe
mysqladmin = /usr/local/bin/mysqladmin
user = mysql
log = /var/log/multi_mysql.log

# Port 3306 Server
[mysqld1]
>socket = /tmp/mysql_3306.sock
port = 3306
pid-file = /var/lib/mysql/mysql_3306.pid
datadir = /var/lib/mysql/
user = mysql
Agora você pode ter a seção [mysqld] do seu arquivo my.cnf e copiá-lo para este local.

cat /etc/my.cnf >> /etc/multi_my.cnf
Se você usar o comando acima de edição para limpar assim você só tem a seção [mysqld] copiados.

Você pode, então, criar a seção porta 3307.
# Port 3307 Server
[mysqld2]
socket = /tmp/mysql_3307.sock
port = 3307
pid-file = /var/lib/mysql2/mysql_3307.pid
datadir = /var/lib/mysql2/
user = mysql
E exemplo de configuração podem ser encontrados aqui:
http://dev.mysql.com/doc/refman/5.6/en/mysqld-multi.html

Para este exemplo vou supor que você vai criar um backup de servidor Porto 3306 com Percona Xtrabackup e colocá-lo no novo datadir.
innobackupex --defaults-file=/etc/my.cnf --user=root --password=<password> --port=3306 --no-timestamp /var/lib/mysql2/
innobackupex --apply-log /var/lib/mysql2/
Agora você pode testar isso agora com o binário mysqld_multi (/ usr / bin / mysqld_multi) ou configurar a iniciar e parar o script. Um modelo vem com o MySQL instalação: / usr / share / mysql / mysqld_multi.server

Você pode copiar isso para o diretório init.d ou testá-lo a partir da localização actual.
O script será o padrão para o arquivo / etc / my.cnf. Então, para começar a testar isso com o - default_file relatório = / etc / multi_my.cnf

A opção de relatório é semelhante ao argumento de status para ver se o servidor está em execução. Se você optar por executar este como o processo padrão, você pode ligar simbolicamente ou copiar o / etc / multi_my.cnf como o novo / etc / my.cnf
/etc/init.d/mysqld_multi.server report 1,2
/etc/init.d/mysqld_multi.server report 1
/etc/init.d/mysqld_multi.server report 2

O código acima, em seguida, dar-lhe execução de status para cada argumento de dar esse curso de referências para uma instância MySQL diferente. Você pode fazer o mesmo a todas as seguintes opções: {start | stop | relatório | restart}

Se tudo correu bem, você pode "começar a 2", que irá iniciar a instância na porta 3307. Em seguida, faça o login e mudar mestre com a informação da posição do log binário fornecido no arquivo xtrabackup_binlog_info.
CHANGE MASTER TO
MASTER_HOST='localhost',
MASTER_PORT=3306,
MASTER_LOG_FILE='<log filename>',
MASTER_LOG_POS=<position>;

Start slave;
Até agora você tem uma cópia de seu servidor escravo secundário. Se estiver usando pt-slave-delay você pode executar o seguinte comando, o padrão é uma hora de atraso.
pt-slave-delay --port=3307 --socket=/tmp/mysql_3307.sock --host=localhost

Espero que este pode pelo menos começar.

sexta-feira, 6 de setembro de 2013

Acesso MySQL e replicação bloqueada por secure_auth

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-access-and-replication-blocked-by.html

ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

Se você já tentou se conectar a um banco de dados MySQL e você verá este erro, então você precisa ter uma senha de hash 41byte válido. Se você não tem certeza que você tem executar o SQL abaixo. Se você tem 16 senhas com caracteres que são senhas mais velhos.

select Password from mysql.user;

O seguinte é como eu resolvi isso como parte de uma migração do MySQL 5.0 para o MySQL 5.6.

O servidor MySQL 5.0 tinha uma mistura dos mais velhos pré 4.1 e senhas 41byte válidos. Como o servidor MySQL 5.0 tinha algumas contas com as senhas mais velhos que eu decidi não descarregar a tabela MySQL como parte da configuração de replicação. Eu fiz despejar todos os bancos de dados, exceto o banco de dados mysql. Isso permitirá que garantiu que eu iria manter os MySQL 5.6 melhorias tabela válidos.

O servidor MySQL 5.6 instalado facilmente e foi para cima e eu carreguei os dados de despejo. Parte da migração era usar replicação, enquanto eles avaliaram o novo banco de dados. Enquanto no servidor MySQL 5.6 Eu testei a conta de usuário de replicação. A resposta que recebi foi o erro no topo desta página. Replicação não irá correr naturalmente sem uma conta de usuário válida. É por isso que os logs de erro foi me dando esse erro:
[ERROR] Slave I/O: error connecting to master '<user>@<hostname>:3306' - retry-time: 10 retries: 68, Error_code: 2049

Uma rápida revisão da conta no servidor MySQL 5.0 mostrou que a nova conta foi criada com a senha pré 4.1. Então, eu precisava atualizar a conta para uma senha de 41 byte válido.

A consulta a seguir mostrou que eles realmente têm senhas antigas habilitado. Então eu tenho que desativar isso e atualizar a conta de usuário novamente para definir a senha como um 41 byte de hash válido.

>SELECT @@session.old_passwords, @@global.old_passwords;
+-------------------------+------------------------+
| @@session.old_passwords | @@global.old_passwords |
+-------------------------+------------------------+
| 1 | 1 |
+-------------------------+------------------------+
1 row in set (0.00 sec)


>SET @@session.old_passwords = 0;
Query OK, 0 rows affected (0.00 sec)

>GRANT REPLICATION SLAVE ON *.* TO '<user>'@'<ip_address>' IDENTIFIED BY '<Password>';
Query OK, 0 rows affected (0.00 sec)

A verificação da senha mostrou a senha como a senha 41byte agora. Eu estava presente capaz de se conectar ao servidor primário do servidor secundário e evitar o erro secure_auth. replicação conectado com facilidade e problema foi resolvido.

Daqui para frente eu precisava para obter o MySQL 5.0 contas de usuários no servidor MySQL 5.6. (Já que eu saltei-los como parte da construção do servidor secundário.)

O cliente precisava definir as bolsas novamente para cada usuário, independentemente de senha válida ou não.
Então, eu instruí-los para executar o seguinte sql. Eu poderia ter feito isso, mas eu preciso saber todas as suas senhas e que não era necessário.

Para cada usuário em seu sistema. Você não tem que fazer o root porque você já tem uma conta root válido no sistema 5.6.

>SET @@session.old_passwords = 0;
>show grants for '<User>'@'<Host>';
Para reunir o sql necessários para cada usuário execute o seguinte:
SELECT CONCAT("SHOW GRANTS FOR '",User,"'@'",Host,"';") as sql_command from mysql.user;

Para cada resultado deu executar a instrução "mostra doações" e, em seguida, executar a instrução dada.
As declarações devem ser semelhante ao seguinte:

GRANT USAGE ON *.* TO 'bob'@'%.example.org' IDENTIFIED BY 'cleartext password';

Replicação então criado e preenchido a tabela MySQL no servidor MySQL 5.6.

Mais pode ser encontrado aqui:
http://dev.mysql.com/doc/refman/5.6/en/password-hashing.html

segunda-feira, 2 de setembro de 2013

MySQL Otimização Dica - thread_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-optimization-tip-threadcachesize.html

 Recentemente eu encontrei um banco de dados MySQL, que facilmente foi executado com 300 a 600 linhas na processlist. As ligações de Max foi criado facilmente mais de duas vezes esse valor também. Este foi um set up que eu só não concordo com ele. Fui chamado porque ele também provou não estar funcionando muito bem. Então, aqui estão alguns dos meus pensamentos sobre o processo eu descobri.

Na minha opinião a maioria dos bancos de dados MySQL em uso não vai precisar de conexões max ou 1500 ou mais. Quanto mais conexões você permitir maior a sobrecarga trazer para o seu servidor. Use suas conexões de forma eficiente.
Em segundo lugar, compreender a% de Threads_created contra as conexões usadas. Você pode considerar isso, os tópicos criados taxa de acerto. BTW .. Isso não é informação nova, esta é uma informação que tem sido entendido na comunidade por algum tempo. Não tenho a pretensão de apresentar este em qualquer outra forma de tentar ajudar os outros. Então, faça o seguinte para compreender o seu atual%
mostram o status como "Threads_created ';
set @ Threads_created = <resultado de consulta acima>;
mostram o status como 'Conexões';
set @ Connections = <resultado de consulta acima>;
selecionar 100 - ((@ Threads_create / @ Connections) * 100) como "Threads_created% das conexões" \ G



Portanto, se seu executar o processo acima do que é o seu percentual? Você quer que isso seja o mais próximo possível de 100. Assim, por exemplo, o servidor de I recentemente encontrado tinha uma% abaixo de 10%. Assim como você corrigir isso e levantar a%?


A variável thread_cache_size tem um padrão de 0. Se você começar a notar o seu processo de crescimento e mas as consultas não estão bloqueadas por impasses e etc, então você deve verificar o seu "Threads_created% das conexões" como mencionado acima. É provável que o seu% será baixo. Você pode aumentar a% e melhorar drasticamente o desempenho do seu banco de dados, encontrando o ponto ideal que se encaixam no seu ambiente de servidor. O thread_cache_size pode ser alterada em um ambiente vivo. Então, isso permite que você defina a variável em seguida, monitorar o valor do status de "Threads_created" (veja acima para obter valor). Se isso continua a incrementar em valor, em seguida, continuar a aumentar a thread_cache_size . Normalmente preferem I para aumentar o valor de 25 por vez para alguns mova para 500 de cada vez. Costumo marcar a opção "Threads_created% das conexões" e "Threads_created. Uma vez que você chegar perto do ponto doce você vai notar a% de ganhar eo processlist começar a cair em linhas. Normalmente mais um ajuste do thread_cache_size vai chegar no ponto ideal.

Cada servidor de ambiente e é diferente.
Alguns servidores podem ser de 98% com uma thread_cache_size de 50, enquanto outros têm um 98% com o thread_cache_size definido para 15000. O máximo é 16384.

Então, se nada mais ... descobrir qual o seu percentual é primeiro e depois olhar para fazer ajustes.