Wodin's questions

Eu tenho uma tabela de 192 GB à qual comecei a adicionar um índice durante a noite.

Isso ainda estava acontecendo várias horas depois.

Na hora que alter tableiniciou o banco de dados estava muito tranquilo.

Havia outras consultas tentando ser executadas durante esse período, incluindo alguns cron jobs, então, quando acordei, havia várias cópias de algumas dessas consultas bloqueadas nesta adição de índice. Eu tentei matar o ALTER TABLE, mas ainda está mostrando:

204997797      root       localhost     web_db      23793 Killed manage k alter table reports add key requisition_ix (requisition_id)

Eu também matei as outras consultas que estavam sendo executadas durante a noite, mas ainda não parei novas conexões com o banco de dados.

Existe uma maneira de forçar matá-lo?

percona-xtradb-cluster-server-5.5 (atualmente autônomo)

Atualmente, há 376 GB de espaço disponível no servidor. Existe no #sql-5db_c3804a5.frmarquivo, mas não há outros arquivos temporários que eu possa ver.

No error.logeu vejo coisas assim:

211015  8:07:22 [ERROR] Table web_db/reports contains 14 indexes inside InnoDB, which is different from the number of indexes 13 defined in the MySQL

Se não houver absolutamente nenhuma maneira de eliminá-lo, existe uma maneira de monitorar o progresso da adição/reversão do índice?

Achei a seguinte palestra de Zardosht Kasheff esclarecedora:

http://www.infoq.com/presentations/Index-SQL

mas cobre apenas o caso de consultas simples em uma única tabela.

Existe algo semelhante para consultas envolvendo várias tabelas? Possivelmente incluindo GROUP BY?

Estou procurando algumas teorias/diretrizes que posso aplicar ao MySQL com o mecanismo de armazenamento InnoDB.

Estou tendo falhas ao tentar executar innobackupex --apply-log. Como posso descobrir quais arquivos ele está processando no momento? Não vejo uma opção relevante mencionada na documentação.

Estamos atualizando o hardware para um servidor de banco de dados MySQL (o banco de dados tem cerca de 200 GB). Estamos obtendo 4x SSDs Samsung 850 Pro e planejamos executá-los em uma configuração RAID10. Além disso, 128 GB de RAM.

A cotação do nosso fornecedor inclui Xeons duplos de 6 núcleos (E5-2620V2 2.1G) com uma opção de atualização para E5-2630V2 2.6G.

O preço das CPUs mais rápidas seria de cerca de US$ 622 a mais (cerca de US$ 311 cada), o que representa cerca de 6,5% do preço do servidor.

Como não temos o hardware, é claro, não posso compará-lo e ver se as CPUs mais rápidas fariam diferença para nosso banco de dados e a maneira como o consultamos. Mas existe alguma maneira de ter uma ideia se as CPUs mais rápidas ajudarão? ou seja, supondo que o gargalo atual seja E/S e substituamos os discos por SSDs, é possível/provável que as CPUs E5-2620V2 se tornem o gargalo?

Obrigado.

Qual a importância de os nós em um cluster do Galera serem idênticos?

Eu encontrei esta resposta que diz que eles devem ser os mesmos: https://dba.stackexchange.com/a/55224/770

Eu entendo que você não deve ter um nó muito lento em comparação com os outros, mas se os nós usam os mesmos discos, a mesma quantidade de RAM e CPUs semelhantes, isso não deveria ser bom o suficiente?

Eu tenho uma tabela com cerca de 30 milhões de linhas no MySQL 5.5 usando o mecanismo de armazenamento InnoDB. Esta tabela possui uma chave estrangeira que se conecta a outra tabela com cerca de 3 milhões de linhas.

Desejo adicionar uma chave primária à tabela maior, mas não tenho certeza da melhor forma de fazer isso. Não há nenhuma coluna existente (ou conjunto de colunas) que eu possa usar para isso, então como devo fazer isso?

Eu vi algumas referências a um ID de registro interno do InnoDB, mas não encontrei se isso é acessível.

Caso contrário, talvez eu precise despejar e recarregar os dados, adicionando o id manualmente.

Obrigado.