Início / user-6131

Max's questions

Martin Hope
Max
Asked: 2013-04-11 07:20:53 +0800 CST
  • 3

Do jeito que as coisas estão, as ações de chave estrangeira em cascata não ativam gatilhos com MySQL. Não quero entrar no debate se isso é bom ou não, só gostaria de saber se existe uma solução alternativa para isso.

Atualmente estou usando triggerspara fazer algo assim:

CREATE TRIGGER `Set_field1_on_update` BEFORE UPDATE ON `mytable`
FOR EACH ROW BEGIN
    SET NEW.field1 =  CONCAT(NEW.myforeignkey,'whatever');
END

O que funciona bem quando myforeignkeyé alterado diretamente, mytablemas não quando é atualizado por ON UPDATE CASCADEmeio de sua tabela referenciada.

Existe alguma maneira de obter a funcionalidade acima (usando algo diferente de gatilhos, se necessário) em ações de chave estrangeira em cascata?

mysql trigger
Martin Hope
Max
Asked: 2012-05-15 05:14:03 +0800 CST
  • 5

Estou tentando importar um mysqldumpbackup de um drupalbanco de dados obtido de um servidor em execução MySQL 5.0(que será atualizado para 5.5) para minha máquina local em execução MySQL 5.5.23. A importação falha com o erro abaixo:

ERROR 1100 (HY000) at line 11084: Table 'search_index' was not locked with LOCK TABLES

Quando abro o backup na linha, 11084aqui está o que recebo:

LOCK TABLES `sessions` WRITE;
/*!40000 ALTER TABLE `sessions` DISABLE KEYS */;
INSERT INTO `sessions` VALUES ...
-- MySQL dump 10.11
--
-- Host: localhost    Database: drupal
-- ------------------------------------------------------
-- Server version       5.0.77-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `search_index`
--

DROP TABLE IF EXISTS `search_index`;        <=== LINE 11084
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `search_index` (
  `word` varchar(50) NOT NULL default '',
  `sid` int(10) unsigned NOT NULL default '0',
  `type` varchar(16) default NULL,
  `score` float default NULL,
  UNIQUE KEY `word_sid_type` (`word`,`sid`,`type`),
  KEY `sid_type` (`sid`,`type`),
  KEY `word` (`word`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SET character_set_client = @saved_cs_client;

Eu verifiquei as outras instruções e normalmente INSERTas instruções são seguidas por UNLOCK TABLES;. Assim, se eu fizer as modificações abaixo no mysqldumparquivo, o problema será corrigido :

INSERT INTO `sessions` VALUES ...
UNLOCK TABLES;                   <=== ADDED LINE
-- MySQL dump 10.11
[...]
DROP TABLE IF EXISTS `search_index`;

Não sei o que há de errado, mas todo o bloco de comentários que começa com -- MySQL dump 10.11é o mesmo do início do mysqldumparquivo, e parece que mysqldumpiniciou um novo despejo ao escrever as INSERT INTO sessionsinstruções que não foram fechadas corretamente com UNLOCK TABLES;.

Alguém tem alguma ideia do que está acontecendo aqui?

mysql mysqldump
Martin Hope
Max
Asked: 2012-04-25 04:59:45 +0800 CST
  • 7

Recentemente, um de nossos servidores ficou sem memória e travou. Depois de revisar os muningráficos, parece que a única métrica (além do uso de memória) que atingiu o pico pouco antes da falha foi o MySQL throughput. No entanto, esperávamos ver um aumento correspondente no número MySQL queries, o que não aconteceu:

insira a descrição da imagem aqui insira a descrição da imagem aqui

Gostaríamos de descobrir o que causou esse pico na taxa de transferência do MySQL. Aqui está a lista de logs do bin da falha:

101M Apr 17 01:27 drupal_master-bin.001270
106M Apr 17 03:00 drupal_master-bin.001271
101M Apr 17 04:05 drupal_master-bin.001272
104M Apr 17 05:53 drupal_master-bin.001273
104M Apr 17 06:39 drupal_master-bin.001274
101M Apr 17 07:02 drupal_master-bin.001275
104M Apr 17 07:22 drupal_master-bin.001276  # 100M filled up in 1 min
106M Apr 17 07:23 drupal_master-bin.001277
101M Apr 17 07:33 drupal_master-bin.001278
101M Apr 17 07:43 drupal_master-bin.001279
104M Apr 17 07:46 drupal_master-bin.001280
102M Apr 17 08:29 drupal_master-bin.001281
102M Apr 17 08:46 drupal_master-bin.001282
105M Apr 17 08:54 drupal_master-bin.001283
 13M Apr 17 09:26 drupal_master-bin.001284  # crash of server around 09:50
# prior to crashing load went very high (we saw 45) and server was extremely slow (few min delay when typing in an SSH session)
101M Apr 17 10:54 drupal_master-bin.001285  # server up again, nothing wrong since then

Eu tenho procurado ferramentas para analisar esses logs bin. Até agora encontrei:

binlog-analyze.pl : me dá uma visão geral das consultas processadas, com detalhamento em select, insert, update.. (para sua informação, substituí select intopor selectno script, pois parecia errado).

$ mysqlbinlog /path/to/bin.log | binlog-analyze.pl -v

pt-query-digest : fornece estatísticas sobre o tamanho da consulta (min, max, avg...). Esse utilitário tem muitas opções, mas não sei o que procurar.

$ mysqlbinlog /path/to/bin.log | pt-query-digest

O que gostaríamos de descobrir é quais consultas geraram o aumento na saída do MySQL.

Alguém pode dar instruções sobre como revisar os logs bin do MySQL para identificar consultas que geram um aumento repentino na taxa de transferência do MySQL?

mysql performance
Martin Hope
Max
Asked: 2012-01-26 07:28:06 +0800 CST
  • 8

Quando verifico o tamanho dos meus bancos de dados no MySQL, recebo isto:

MariaDB [(none)]> SELECT table_schema "Data Base Name",  sum( data_length + index_length ) / 1024 /  1024 "Data Base Size in MB",  sum( data_free )/ 1024 / 1024 "Free Space in MB"  FROM information_schema.TABLES  GROUP BY table_schema;
+--------------------+----------------------+------------------+
| Data Base Name     | Data Base Size in MB | Free Space in MB |
+--------------------+----------------------+------------------+
| alfresco           |         245.75000000 |      34.00000000 |
| drupal             |         892.15625000 |     216.00000000 |
+--------------------+----------------------+------------------+

Quando verifico o tamanho no disco, recebo isto:

$ sudo du -h --max-depth=1 /var/lib/mysql/
317M    /var/lib/mysql/alfresco
1.4G    /var/lib/mysql/drupal

Se eu combinar o espaço usado e livre fornecido por Maria DB e compará-lo com os números do disco, tenho o seguinte:

alfresco: DB=279MB  DISK=317MB (+14%)
drupal: DB=1100MB   DISK=1433MB (+30%)

P: É normal ter tanta sobrecarga no disco/Há algo que eu possa fazer para reduzi-la?

Para sua informação, pensei que executar uma otimização mysql ajudaria ( usando esse comando ), reduziu o tamanho dos bancos de dados, mas não alterou o tamanho dos arquivos no disco.

Informação adicional:

server:             ubuntu server 10.04 LTS
DB server:          MariaDB
DB engine:          InnoDB v10 (for all tables)
Table collation:    utf8_general_ci
Nb Drupal tables:   416  (0.80MB overhead per table)
Nb Alfresco tables: 84   (0.45MB overhead per table)
mysql ubuntu