amatusko's questions

Temos uma situação em que gostaríamos de ter replicação síncrona em nosso data center principal, mas replicar de forma assíncrona em outra região. Nosso segundo data center fica a 3.000 milhas de distância (Site B) e o usamos como um backup quente caso precisemos fazer failover de nosso data center principal (Site A) devido a uma falha no data center.

Não estamos armazenando nenhum dado financeiro ou transacionalmente sensível. Nossos dados são importantes, é claro, mas não são críticos nesse grau, pois consistem principalmente em atualizações de conteúdo do site de editores de conteúdo.

Estamos interessados ​​em usar Percona XtraDB ou Galera Cluster no Site A combinado com algo como MySQL, MariaDB ou Percona Server para o Site B, mas não sabemos se isso é possível ou como podemos implementar tal solução. Podemos ter um esquema de replicação síncrona no Site A com um backup assíncrono para os servidores do Site B? Seria possível manter uma implementação multimestre no Site A com réplicas no Site B?

Se for possível, suponho que exigiria várias tecnologias. Quais tecnologias ou configurações são soluções viáveis?

Existe uma versão do "procedimento de criação ou substituição" para o MySQL? Não consigo fazer isso ou script a eliminação do procedimento se existir antes de recompilar sem receber uma mensagem de erro informando que o procedimento armazenado existe.

DELIMITER $$

-- would love to be able to drop procedure if exists db.sp_tmp_90days;  
-- or use "create or replace"

create procedure db.sp_tmp_90days()

BEGIN
drop table db.tmp_90days;

create table db.tmp_90days ( 
    user_name varchar(128), 
    first_name varchar(50), 
    last_name varchar(50), 
    system varchar(10), 
    last_login datetime 
);

alter table db.tmp_90days add index idx_user_name(user_name);
alter table db.tmp_90days add index idx_system(system);
alter table db.tmp_90days add index idx_last_login(last_login);

insert into db.tmp_90days (user_name, first_name, last_name, system, last_login)
    SELECT
        [...]
END $$

Estamos testando a replicação usando GTIDs em dois servidores executando o MySQL 5.6. A replicação estava funcionando bem, mas agora não está funcionando. Quando executo show slave status\Gno slave, recebo a seguinte mensagem de erro

Last_IO_Errno: 1236 Last_IO_Error: Erro fatal 1236 do mestre ao ler dados do log binário: 'O escravo tem mais GTIDs do que o mestre, usando o SERVER_UUID do mestre. Isso pode indicar que o final do log binário foi truncado ou que o último arquivo de log binário foi perdido, por exemplo, após uma falha de energia ou disco quando sync_binlog != 1. O mestre pode ou não ter revertido transações que já eram réplicas '

Tentei redefinir o mestre e parar, redefinir e reiniciar o escravo, sem sorte, e não consigo encontrar nenhuma informação sobre esse problema específico online.

Estranhamente, ao verificar show slave status\Go mestre, recebo um erro diferente.

Last_Errno: 1007 Last_Error: Erro 'Não é possível criar banco de dados 'repltest'; banco de dados existe' na consulta. Banco de dados padrão: 'repltest'. Consulta: 'criar banco de dados repltest'

Mas quando verifico o slave e o master, o banco de dados 'repltest' não existe. Este era apenas um banco de dados que criamos no mestre para verificar se a replicação estava funcionando e o excluímos do mestre posteriormente.

Editar - Observação: este é um ambiente de preparação que não possui conexões de banco de dados ativas de nenhum aplicativo. Isso foi configurado apenas para testar a replicação com GTIDs

Estou tendo um pouco de dificuldade em obter resultados precisos de uma consulta que me parece que deveria funcionar. RDBMS é MySQL.

Estou tentando obter a data máxima do último login de uma seleção de união em três bancos de dados para produtos Atlassian JIRA, Confluence e Stash. Deve haver apenas uma única entrada nos resultados para cada usuário (o max(Last_Login) deve obter a data máxima do último login e mostrar um resultado se esse max(Last_Login) for mais antigo que hoje - 90 dias.

Resumi a saída da consulta de união e, em seguida, seleciono a partir desse agregado para que eu possa obter a data máxima de login que é 90 dias atrás ou antes.

O problema: a consulta parece funcionar na maior parte, mas há alguns casos em que um usuário mostra atividade nas interfaces Confluence, Stash ou JIRA que são mais recentes do que as que tenho aqui.

Aqui está a consulta que estou tentando usar:

select
    User_Name,
    First_Name,
    Last_Name,
    max(Last_Login) as Last_Login
FROM
(
SELECT
    u.user_name as User_Name,
    u.first_name as First_Name,
    u.last_name Last_Name,
    ifnull(from_unixtime((cast(a.attribute_value AS UNSIGNED)/1000), '%Y-%m-%d'), '1970-01-01') AS Last_Login
FROM jira.cwd_user u
  LEFT JOIN jira.cwd_user_attributes a ON u.id = a.user_id AND a.attribute_name = 'login.lastLoginMillis'
  JOIN jira.cwd_directory d ON u.directory_id = d.id
where u.active = 1
UNION
select
    u.user_name as User_Name,
    u.first_name as First_Name,
    u.last_name Last_Name, 
    ifnull(from_unixtime((cast(ca.attribute_value AS UNSIGNED)/1000), '%Y-%m-%d'), '1970-01-01') AS Last_Login
FROM confluence.cwd_user u
  LEFT JOIN confluence.cwd_user_attribute ca ON u.id = ca.user_id AND ca.attribute_name = 'login.lastLoginMillis'
  JOIN confluence.cwd_directory d ON u.directory_id = d.id
where u.active = 'T'
UNION
select
    u.user_name as User_Name,
    u.first_name as First_Name,
    u.last_name Last_Name,
    ifnull(from_unixtime((cast(sa.attribute_value AS UNSIGNED)/1000), '%Y-%m-%d'), '1970-01-01') AS Last_Login
FROM stash.cwd_user u
LEFT JOIN stash.cwd_user_attribute sa ON u.id = sa.user_id AND sa.attribute_name = 'login.lastLoginMillis'
JOIN stash.cwd_directory d ON u.directory_id = d.id
where u.is_active = 'T'
) as z
group by User_Name, First_Name, Last_Name
having (max(Last_Login)) <= date_sub(now(), interval 90 day)
order by User_Name asc, Last_Login desc