ypercubeᵀᴹ's questions

Temos um servidor escravo que interrompeu a replicação devido ao seguinte erro:

Slave SQL: Query caused different errors on master and slave.

Qual poderia ser a causa desse erro? E qual seria uma maneira de consertar isso?

A versão do mestre e do escravo é MySQL 5.5.30

130726 23:55:45 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

130726 23:58:39 [Note] Plugin 'FEDERATED' is disabled.
130726 23:58:39 [Warning] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ignoring option '--innodb-file-per-table' due to invalid value 'ON'
130726 23:58:39 [Note] Plugin 'InnoDB' is disabled.
130726 23:58:39 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130726 23:58:39 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130726 23:58:39 [Note] Server socket created on IP: '0.0.0.0'.
130726 23:58:39 [Note] Slave SQL thread initialized, starting replication 
    in log 'mysql-bin.000234' at position 1065421256, 
    relay log '.\slave-relay-bin.000917' position: 1065421402
130726 23:58:39 [Note] Slave I/O thread: connected to master '[email protected]:3306',
    replication started in log 'mysql-bin.000235' at position 166680598
130726 23:58:39 [Note] Event Scheduler: Loaded 0 events
130726 23:58:39 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: 
    ready for connections.
Version: '5.5.30-log'  socket: ''  port: 3306  MySQL Community Server (GPL)
130726 23:59:04 [ERROR] Slave SQL: Query caused different errors on master and slave.
    Error on master: message (format)='Incorrect key file for table '%-.200s'; 
    try to repair it' error code=1034 ; 
    Error on slave: actual message='no error', error code=0. 
    Default database: 'shared'. 
    Query: 'CREATE TEMPORARY TABLE tmp_grades (
                        vehsysid INT(11),
                        grade INT(1),
                        dt TIMESTAMP,
                        INDEX(vehsysid),
                        INDEX(grade),
                        INDEX(dt)
                    ) SELECT vehsysid, Grade, MAX(dt) AS dt
                        FROM shared.tbl_valuations 
                        GROUP BY vehsysid, grade', Error_code: 0
130726 23:59:04 [ERROR] Error running query, slave SQL thread aborted. Fix the problem,
   and restart the slave SQL thread with "SLAVE START". 
   We stopped at log 'mysql-bin.000234' position 1065421256

O que mais não consigo descobrir é como uma tabela temporária levaria a esse erro (no mestre):
'Incorrect key file for table '%-.200s'; try to repair it' error code=1034

As últimas linhas do log de erros mestre:

130725 23:15:57 [Warning] Warning: Enabling keys got errno 120 on shared.tmp_grades, retrying
130726 23:15:58 [Warning] Warning: Enabling keys got errno 137 on shared.tmp_grades, retrying

Informação adicional:

• tanto o Master quanto o Slave rodam no Windows (não sei se isso é relevante).
• os discos em ambos têm muito espaço.
• formato de replicação éMIXED
• innodb é ignorado em todas as instâncias, master e slaves. MyISAM é o padrão.

Fazendo esta pergunta, especificamente para Postgres, pois tem bom suporte para índices R-tree/espaciais.

Temos a seguinte tabela com uma estrutura em árvore (modelo Nested Set) de palavras e suas frequências:

lexikon
-------
_id   integer  PRIMARY KEY
word  text
frequency integer
lset  integer  UNIQUE KEY
rset  integer  UNIQUE KEY

E a consulta:

SELECT word
FROM lexikon
WHERE lset BETWEEN @Low AND @High
ORDER BY frequency DESC
LIMIT @N

Suponho que um índice de cobertura (lset, frequency, word)seria útil, mas sinto que pode não funcionar bem se houver muitos lsetvalores no (@High, @Low)intervalo.

Às vezes, um índice simples (frequency DESC)também pode ser suficiente, quando uma pesquisa usando esse índice produz antecipadamente as @Nlinhas que correspondem à condição de intervalo.

Mas parece que o desempenho depende muito dos valores dos parâmetros.

Existe uma maneira de torná-lo rápido, independentemente de o intervalo (@Low, @High)ser amplo ou estreito e independentemente de as palavras de frequência superior estarem felizmente no intervalo (estreito) selecionado?

Um índice R-tree/espacial ajudaria?

Adicionar índices, reescrever a consulta, redesenhar a tabela, não há limitação.

Inspirado por uma questão de modelagem Django: Modelagem de banco de dados com múltiplas relações muitos-para-muitos em Django . O db-design é algo como:

CREATE TABLE Book
( BookID INT NOT NULL
, BookTitle VARCHAR(200) NOT NULL
, PRIMARY KEY (BookID)
) ;

CREATE TABLE Tag
( TagID INT NOT NULL
, TagName VARCHAR(50) NOT NULL
, PRIMARY KEY (TagID)
) ;

CREATE TABLE BookTag
( BookID INT NOT NULL
, TagID INT NOT NULL
, PRIMARY KEY (BookID, TagID)
, FOREIGN KEY (BookID)  REFERENCES Book (BookID)
, FOREIGN KEY (TagID)   REFERENCES Tag (TagID)
) ;

CREATE TABLE Aspect
( AspectID INT NOT NULL
, AspectName VARCHAR(50) NOT NULL
, PRIMARY KEY (AspectID)
) ;

CREATE TABLE TagAspect
( TagID INT NOT NULL
, AspectID INT NOT NULL
, PRIMARY KEY (TagID, AspectID) 
, FOREIGN KEY (TagID)   REFERENCES Tag (TagID)
, FOREIGN KEY (AspectID)  REFERENCES Aspect (AspectID)
) ;

e a questão é como definir a BookAspectRatingtabela e reforçar a integridade referencial, de modo que não se possa adicionar uma classificação para uma (Book, Aspect)combinação inválida.

CHECKAFAIK, restrições complexas (ou ASSERTIONS) que envolvem subconsultas e mais de uma tabela, que possivelmente poderiam resolver isso, não estão disponíveis em nenhum SGBD.

Outra ideia é usar (pseudocódigo) uma visão:

CREATE VIEW BookAspect_view
  AS
SELECT DISTINCT
    bt.BookId
  , ta.AspectId
FROM 
    BookTag AS bt
  JOIN 
    Tag AS t  ON t.TagID = bt.TagID
  JOIN 
    TagAspect AS ta  ON ta.TagID = bt.TagID 
WITH PRIMARY KEY (BookId, AspectId) ;

e uma tabela que possui uma Chave Estrangeira para a View acima:

CREATE TABLE BookAspectRating
( BookID INT NOT NULL
, AspectID INT NOT NULL
, PersonID INT NOT NULL
, Rating INT NOT NULL
, PRIMARY KEY (BookID, AspectID, PersonID)
, FOREIGN KEY (PersonID)   REFERENCES Person (PersonID)
, FOREIGN KEY (BookID, AspectID) 
    REFERENCES BookAspect_view (BookID, AspectID)
) ;

Três perguntas:

• Existem DBMS que permitem um (possivelmente materializado) VIEWcom um PRIMARY KEY?

• Existem SGBDs que permitem um FOREIGN KEYque REFERENCESum VIEW(e não apenas um base TABLE)?

• Esse problema de integridade poderia ser resolvido de outra forma - com recursos de DBMS disponíveis?

Esclarecimento:

Já que provavelmente não existe uma solução 100% satisfatória - e a questão do Django nem é minha! - Estou mais interessado em uma estratégia geral de possível ataque ao problema, não em uma solução detalhada. Portanto, uma resposta como "no DBMS-X isso pode ser feito com triggers na tabela A" é perfeitamente aceitável.