Deadlock no SEI
-
14 de Julho de 2017 às 11:42Bom dia a todos,
Pessoal, estou encontrando várias referências no LOG para deadlock no SEI. Alguém sabe me informar se isso é alguma configuração de banco de dados que está incorreta? Estamos com o MySQL (PerconaDB).
Muito obrigado.
Erro: Deadlock found when trying to get lock; try restarting transaction
Detalhes:
SELECT publicacao.id_documento AS iddocumento,veiculo_publicacao.sta_tipo AS statipoveiculopublicacao,veiculo_publicacao.nome AS nomeveiculopublicacao,publicacao.dta_disponibilizacao AS disponibilizacao,publicacao.dta_publicacao AS publicacao,publicacao.numero,publicacao.id_veiculo_io AS idveiculoio,publicacao.dta_publicacao_io AS publicacaoio,publicacao.pagina_io AS paginaio,veiculo_imprensa_nacional.sigla AS siglaveiculoimprensanacional,secao_imprensa_nacional.nome AS nomesecaoimprensanacional FROM publicacao INNER JOIN veiculo_publicacao ON publicacao.id_veiculo_publicacao=veiculo_publicacao.id_veiculo_publicacao LEFT JOIN veiculo_imprensa_nacional ON publicacao.id_veiculo_io=veiculo_imprensa_nacional.id_veiculo_imprensa_nacional LEFT JOIN secao_imprensa_nacional ON publicacao.id_secao_io=secao_imprensa_nacional.id_secao_imprensa_nacional WHERE publicacao.id_documento=12335
Trilha de Processamento:
0 /opt/infra/infra_php/InfraBD.php(441): InfraMySqli->consultarSql('SELECT publicac...')
1 /opt/infra/infra_php/InfraBD.php(289): InfraBD->listar(Object(PublicacaoDTO), false)
2 /opt/sei/web/rn/PublicacaoRN.php(1184): InfraBD->consultar(Object(PublicacaoDTO))
3 [internal function]: PublicacaoRN->consultarRN1044Conectado(Object(PublicacaoDTO))
4 /opt/infra/infra_php/InfraRN.php(140): call_user_func(Array, Object(PublicacaoDTO))
5 /opt/sei/web/rn/DocumentoRN.php(1419): InfraRN->__call('consultarRN1044', Array)
6 /opt/sei/web/rn/DocumentoRN.php(1419): PublicacaoRN->consultarRN1044(Object(PublicacaoDTO))
7 [internal function]: DocumentoRN->consultarRN0005Conectado(Object(DocumentoDTO))
8 /opt/infra/infra_php/InfraRN.php(140): call_user_func(Array, Object(DocumentoDTO))
9 /opt/sei/web/rn/DocumentoRN.php(3099): InfraRN->__call('consultarRN0005', Array)
10 /opt/sei/web/rn/DocumentoRN.php(3099): DocumentoRN->consultarRN0005(Object(DocumentoDTO))
11 [internal function]: DocumentoRN->validarDocumentoPublicadoRN1211Controlado(Object(DocumentoDTO))
12 /opt/infra/infra_php/InfraRN.php(140): call_user_func(Array, Object(DocumentoDTO))
13 /opt/sei/web/rn/DocumentoRN.php(2384): InfraRN->__call('validarDocument...', Array)
14 /opt/sei/web/rn/DocumentoRN.php(2384): DocumentoRN->validarDocumentoPublicadoRN1211(Object(DocumentoDTO))
15 [internal function]: DocumentoRN->atualizarConteudoRN1205InternoControlado(Object(DocumentoDTO))
16 /opt/infra/infra_php/InfraRN.php(140): call_user_func(Array, Object(DocumentoDTO))
17 /opt/sei/web/rn/DocumentoRN.php(2109): InfraRN->__call('atualizarConteu...', Array)
18 /opt/sei/web/rn/DocumentoRN.php(2109): DocumentoRN->atualizarConteudoRN1205Interno(Object(DocumentoDTO))
19 /opt/sei/web/editor/rn/EditorRN.php(1432): DocumentoRN->atualizarConteudoRN1205(Object(DocumentoDTO))
20 /opt/sei/web/editor/rn/EditorRN.php(902): EditorRN->atualizarConteudo(Object(EditorDTO))
21 [internal function]: EditorRN->gerarVersaoInicialControlado(Object(EditorDTO))
22 /opt/infra/infra_php/InfraRN.php(140): call_user_func(Array, Object(EditorDTO))
23 /opt/sei/web/rn/DocumentoRN.php(456): InfraRN->__call('gerarVersaoInic...', Array)
24 /opt/sei/web/rn/DocumentoRN.php(456): EditorRN->gerarVersaoInicial(Object(EditorDTO))
25 [internal function]: DocumentoRN->cadastrarRN0003InternoControlado(Object(DocumentoDTO))
26 /opt/infra/infra_php/InfraRN.php(140): call_user_func(Array, Object(DocumentoDTO))
27 /opt/sei/web/rn/DocumentoRN.php(31): InfraRN->__call('cadastrarRN0003...', Array)
28 /opt/sei/web/rn/DocumentoRN.php(31): DocumentoRN->cadastrarRN0003Interno(Object(DocumentoDTO))
29 /opt/sei/web/documento_cadastro.php(189): DocumentoRN->cadastrarRN0003(Object(DocumentoDTO))
30 /opt/sei/web/controlador.php(247): require_once('/opt/sei/web/do...')
31 {main}
[cid:image001.jpg@01D2FC7D.085315A0]
João Carlos Lemgruber Junior
Analista em Tecnologia da Informação
Coordenação de Tecnologia da Informação - CTINF/DPGI
Instituto Brasileiro de Museus - IBRAM
joao.lemgruber@museus.gov.br
SBN Quadra 2, Edifício CNC 3 Bloco N 12º andar
Brasília (DF) - CEP 70.040-020
55 61 3521-4073
________________________________
Imprima esta página apenas se necessário.
Ibram Sustentável - Preservando nossa memória e nosso futuro. -
19 de Julho de 2017 às 14:56Joao,
Bom dia. Aqui na Susep nos deparamos com muitos erros de dead lock também, há cerca de dois meses.
Tivemos de criar alguns índices. Cinco no total. Melhorou muito a performance e os erros diminuíram bastante.
Atenciosamente,
Douglas Fiório Dias
De: sei-tecnico [mailto:sei-tecnico-bounces@listas.softwarepublico.gov.br] Em nome de Joao Carlos Lemgruber Junior
Enviada em: sexta-feira, 14 de julho de 2017 08:42
Para: sei-tecnico@listas.softwarepublico.gov.br
Assunto: [GRAYMAIL] [sei-tecnico] Deadlock no SEI[cid:image001.jpg@01CCE577.B75F3240] -
19 de Julho de 2017 às 15:22Prezado João Carlos,
Gostaria de maiores informações sobre o seu ambiente para poder simular o
problema aqui.
- O problema ocorre em alguma funcionalidade específica ou em todo o
sistema? No log menciona consulta específica em tabelas de publicação de
documentos.
- Saberia me dizer qual o tamanho do banco de dados, em megabytes?
- Também estão encontrando lentidão em alguma funcionalidade no SEI?Guilherme Andrade Del Cantoni
Ministério do Planejamento, Desenvolvimento e Gestão
Processo Eletrônico Nacional
Em qua, 19 de jul de 2017 às 11:57, Douglas Fiório Dias <
douglas.dias@susep.gov.br> escreveu:Guilherme Andrade Del Cantoni -
19 de Julho de 2017 às 17:55Prezado Guilherme,
O erro de deadlock ocorreu em duas consultas:
a. SELECT publicacao.id_documento AS iddocumento,veiculo_publicacao.sta_tipo AS statipoveiculopublicacao,veiculo_publicacao.nome AS nomeveiculopublicacao,publicacao.dta_disponibilizacao AS disponibilizacao,publicacao.dta_publicacao AS publicacao,publicacao.numero,publicacao.id_veiculo_io AS idveiculoio,publicacao.dta_publicacao_io AS publicacaoio,publicacao.pagina_io AS paginaio,veiculo_imprensa_nacional.sigla AS siglaveiculoimprensanacional,secao_imprensa_nacional.nome AS nomesecaoimprensanacional FROM publicacao INNER JOIN veiculo_publicacao ON publicacao.id_veiculo_publicacao=veiculo_publicacao.id_veiculo_publicacao LEFT JOIN veiculo_imprensa_nacional ON publicacao.id_veiculo_io=veiculo_imprensa_nacional.id_veiculo_imprensa_nacional LEFT JOIN secao_imprensa_nacional ON publicacao.id_secao_io=secao_imprensa_nacional.id_secao_imprensa_nacional WHERE publicacao.id_documento=12335
b. SELECT assinatura.id_assinatura AS idassinatura,assinatura.id_unidade AS idunidade,usuario.sta_tipo AS statipousuario,usuario.sigla AS siglausuario FROM assinatura INNER JOIN usuario ON assinatura.id_usuario=usuario.id_usuario WHERE assinatura.id_documento=4126 AND assinatura.sin_ativo='S'
Em nosso ambiente, utilizamos o PerconaDB em modo cluster. O Guilherme Campos em resposta ao meu problema informou a respeito sobre este tipo de problema ao utilizar o MySQL em cluster, então estou verificando junto à equipe de infra como podemos minimizar este impacto ou se precisaríamos retirar o SEI do cluster.
Como implantamos o sistema eletrônico no final de junho/2017, ainda temos uma base de dados pequena, (476 Mb) e também não tivemos relatos de lentidão de acesso às funções do sistema.
Obrigado pelo apoio.
[cid:image001.jpg@01D30098.88BE05A0]De: Guilherme Andrade Del Cantoni [mailto:guilhermeadc@gmail.com]
Enviada em: quarta-feira, 19 de julho de 2017 12:23
Para: Douglas Fiório Dias
Assunto: Re: [sei-tecnico] RES: Deadlock no SEIGostaria de maiores informações sobre o seu ambiente para poder simular o problema aqui.
* O problema ocorre em alguma funcionalidade específica ou em todo o sistema? No log menciona consulta específica em tabelas de publicação de documentos.
* Saberia me dizer qual o tamanho do banco de dados, em megabytes?
* Também estão encontrando lentidão em alguma funcionalidade no SEI?Em qua, 19 de jul de 2017 às 11:57, Douglas Fiório DiasDe: sei-tecnico [mailto:sei-tecnico-bounces@listas.softwarepublico.gov.brPara: sei-tecnico@listas.softwarepublico.gov.br[cid:image001.jpg@01D30084.5D8DBF10]55 61 3521-4073
________________________________sei-tecnico@listas.softwarepublico.gov.br11ª Primavera dos Museus: inscrições abertas de 14 de julho a 14 de agosto.
Acesse www.museus.gov.br. -
21 de Julho de 2017 às 12:54OK João Carlos,
Gostaria que você me mandasse informado sobre esta avaliação que está sendo
feita pois pode ser um problema que ocorrerá em outros órgãos e preciso ter
conhecimento de como proceder para fazer os devidos ajustes. Outros órgãos
já mencionaram a intensão de utilizar a configuração de cluster do Mysql.Em qua, 19 de jul de 2017 às 14:55, Joao Carlos Lemgruber Junior <
joao.lemgruber@museus.gov.br> escreveu: -
21 de Julho de 2017 às 15:48Boa tarde pessoal,
Aqui na ESMPU executamos o SEI em banco de dados Oracle_sem RAC_,
portanto minha mensagem é baseada em estudo realizado com cluster mysql
para uso com a aplicação Moodle.
Fiz no ano passado uma POC aqui na ESMPU para usar o cluster galera do
mysql (aqui estudei a implementação percona-xtradb-cluster).
* Um dos problemas observados foi justamente de DEAD LOCK, que, de
acordo com a documentação e com meus testes na época, são causados
quando o mesmo recurso é acessado para escrita ou modificação em
dois ou mais nós do cluster durante transações diferentes. (exemplo,
a aplicação manda um update em um conjunto de dados com 30
registros. Antes de commitar a aplicação manda outro update nos
mesmos 30 registros pelo nó B. Aí ocorre o Deadlock.).
Verifiquei que a situação perfeita para evitar deadlocks desta natureza
no cluster seria a seguinte:
1. A aplicação pode LER dados de qualquer nó do cluster
2. A aplicação só pode ESCREVER em apenas um nó do cluster
O ideal para implementar isso seria fazer com que a aplicação use
conexões distintas para cada tipo de operação.
Por exemplo,
A aplicação usa uma conexão 1 para enviar para o banco qualquer
sentença de alteração de dados. Esta conexão 1 apontaria para para
um grupo de conexões HAProxy no modo failover.
A conexão 2, usada para consultas, apontaria para outro grupo de
conexões HAProxy no modo roundrobin, realizando portanto o
balanceamento de escritas.
Porém nem sempre é fácil alterar a aplicação. No nosso caso do MOODLE é
impossível sem que se perca a compatibilidade com as atualizações da
comunidade.
Para tentar contornar este 'balanceamento inteligente', a oracle criou o
programa MYSQL Router, que teoricamente consegue fazer este
redirecionamento de sentenças para nós específicos.
Porém não consegui usar o plugin adequadamente aqui na ESMPU.
* Outro problema que o cluster pode ter é o de geração de chaves
auto-incremento: É necessário configurar o wsrep com as variáveis
|auto_increment_increment| e |auto_increment_offset. Isso também
matou a possibilidade de utilização com o moodle por causa da forma
com que as chaves eram geradas.|
||Enfim, depois de 2 meses de estudos e a verificação de outros
problemas práticos do uso do cluster em produção, concluí que a
implementação de cluster mysql com a arquitetura igual ou semelhante ao
percona-xtradb-cluster não passa confiança para rodar em produção, pois
precisa de muitas configurações, 'jeitinhos' e instalações para
funcionar com a transparência necessária para uma aplicação do porte do
Moodle.
Aqui, até o momento, tem bastado uma instância mysql bem configurada,
com parâmetros de memória bem balanceada para aguentar o tráfico, um nó
de cluster SLAVE para servir como disponibilidade imediata mínima e a
implementação de backup incrementais a cada hora sem travar o banco
usando a ferramenta percona-xtrabackup.
Grato pela atenção,
|*Guilherme Marques Amaral de Campos *
Chefe do Núcleo de Gerenciamento de Banco de Dados
NUBAN/STI/ESMPU
*Tel: (061) 3313-5386*
Escola Superior do Ministério Público da União | SGAS Av. L2 Sul, Qd.
604 lt 23 - CEP: 70200-640 - Brasília - DF Tel.: (61) 3313 - 5115
|
Em 21/07/2017 09:54, Guilherme Andrade Del Cantoni escreveu: -
21 de Julho de 2017 às 16:36Prezados,
Também temos esses problemas de deadlock usando banco de dados SQLServer 2008 R2 em cluster ativo/passivo, ou seja, um servidor atende toda a carga e se esse servidor cair, o outro que está em espera assume. Atualmente a base de dados está com 150GB.
Criamos 5 índices que minimizou o problema, mas não resolveu (para a versão 3.x do SEI):
CREATE NONCLUSTERED INDEX [i04_documento] ON [dbo].[documento] ([numero],[id_serie]) with (online = on)
CREATE NONCLUSTERED INDEX [i02_atributo_andamento] ON [dbo].[atributo_andamento] ([nome],[id_origem]) with (online = on)
CREATE NONCLUSTERED INDEX [i03_atividade] ON [dbo].[atividade] ([id_unidade],[dth_conclusao],[sin_inicial]) with (online = on)
CREATE NONCLUSTERED INDEX [i02_acesso] ON [dbo].[acesso] ([id_protocolo],[sta_tipo]) with (online = on)
CREATE NONCLUSTERED INDEX [i02_andamento_marcador] ON [dbo].[andamento_marcador] ([id_unidade],[id_procedimento],[sin_ultimo]) with (online = on)
A próxima tentativa seria trocar o nível de isolamento da base, mas, no momento, não temos “braços” para fazer testes robustos e garantir que não gere efeitos colaterais. O pessoal técnico do SEI sugere trabalhar para refinar os índices em vez de fazer a troca do nível de isolamento.
ALTER DATABASE SEI SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE SEI SET ALLOW_SNAPSHOT_ISOLATION ON;
Se algum órgão que usa Oracle não reportar nenhum erro de deadlock é um bom sinal, pois por padrão o Oracle usa um nível de isolamento que, grosseiramente comparando, seria equivalente ao READ_COMMITTED_SNAPSHOT do SQLServer.
Abraços.
Cristiano José Müller
Analista da Informação e Comunicação
cristiano.muller@procempa.com.br
51 3289 6000 / 51 3289 6354
procempa.com.br
tecnologia a serviço da cidade
De: sei-tecnico [mailto:sei-tecnico-bounces@listas.softwarepublico.gov.br] Em nome de Guilherme Marques Amaral de Campos
Enviada em: sexta-feira, 21 de julho de 2017 12:49
Para: Guilherme Andrade Del Cantoni
Assunto: {Spam?} Re: [sei-tecnico] RES: Deadlock no SEIAqui na ESMPU executamos o SEI em banco de dados Oracle sem RAC, portanto minha mensagem é baseada em estudo realizado com cluster mysql para uso com a aplicação Moodle.
Fiz no ano passado uma POC aqui na ESMPU para usar o cluster galera do mysql (aqui estudei a implementação percona-xtradb-cluster).
* Um dos problemas observados foi justamente de DEAD LOCK, que, de acordo com a documentação e com meus testes na época, são causados quando o mesmo recurso é acessado para escrita ou modificação em dois ou mais nós do cluster durante transações diferentes. (exemplo, a aplicação manda um update em um conjunto de dados com 30 registros. Antes de commitar a aplicação manda outro update nos mesmos 30 registros pelo nó B. Aí ocorre o Deadlock.).
Verifiquei que a situação perfeita para evitar deadlocks desta natureza no cluster seria a seguinte:
1. A aplicação pode LER dados de qualquer nó do cluster
2. A aplicação só pode ESCREVER em apenas um nó do cluster
O ideal para implementar isso seria fazer com que a aplicação use conexões distintas para cada tipo de operação.A aplicação usa uma conexão 1 para enviar para o banco qualquer sentença de alteração de dados. Esta conexão 1 apontaria para para um grupo de conexões HAProxy no modo failover.
A conexão 2, usada para consultas, apontaria para outro grupo de conexões HAProxy no modo roundrobin, realizando portanto o balanceamento de escritas.
Porém nem sempre é fácil alterar a aplicação. No nosso caso do MOODLE é impossível sem que se perca a compatibilidade com as atualizações da comunidade.
Para tentar contornar este 'balanceamento inteligente', a oracle criou o programa MYSQL Router, que teoricamente consegue fazer este redirecionamento de sentenças para nós específicos.* Outro problema que o cluster pode ter é o de geração de chaves auto-incremento: É necessário configurar o wsrep com as variáveis auto_increment_increment e auto_increment_offset. Isso também matou a possibilidade de utilização com o moodle por causa da forma com que as chaves eram geradas.
Enfim, depois de 2 meses de estudos e a verificação de outros problemas práticos do uso do cluster em produção, concluí que a implementação de cluster mysql com a arquitetura igual ou semelhante ao percona-xtradb-cluster não passa confiança para rodar em produção, pois precisa de muitas configurações, 'jeitinhos' e instalações para funcionar com a transparência necessária para uma aplicação do porte do Moodle.
Aqui, até o momento, tem bastado uma instância mysql bem configurada, com parâmetros de memória bem balanceada para aguentar o tráfico, um nó de cluster SLAVE para servir como disponibilidade imediata mínima e a implementação de backup incrementais a cada hora sem travar o banco usando a ferramenta percona-xtrabackup.Escola Superior do Ministério Público da União | SGAS Av. L2 Sul, Qd. 604 lt 23 - CEP: 70200-640 - Brasília - DF Tel.: (61) 3313 - 5115Gostaria que você me mandasse informado sobre esta avaliação que está sendo feita pois pode ser um problema que ocorrerá em outros órgãos e preciso ter conhecimento de como proceder para fazer os devidos ajustes. Outros órgãos já mencionaram a intensão de utilizar a configuração de cluster do Mysql.Em qua, 19 de jul de 2017 às 14:55, Joao Carlos Lemgruber Junior[cid:image001.jpg@01D30225.0FA6C6F0]55 61 3521-4073
De: Guilherme Andrade Del Cantoni [mailto:guilhermeadc@gmail.comPara: Douglas Fiório DiasJoão Carlos Lemgruber Junior
Analista em Tecnologia da Informação
Coordenação de Tecnologia da Informação – CTINF/DPGI
Instituto Brasileiro de Museus - IBRAM
joao.lemgruber@museus.gov.br
SBN Quadra 2, Edifício CNC 3 Bloco N 12º andar
Brasília (DF) – CEP 70.040-020
55 61 3521-4073Ibram Sustentável – Preservando nossa memória e nosso futuro.
_______________________________________________https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/sei-tecnico
--
---
Guilherme Andrade Del CantoniAcesse www.museus.gov.br.
--
---
Guilherme Andrade Del Cantoni_______________________________________________
sei-tecnico mailing list
sei-tecnico@listas.softwarepublico.gov.br
https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/sei-tecnico
-- -
Arthur Colombo Duarte
1 de Agosto de 2017 às 14:01Um deadlock ocorre quando um serviço tenta alocar recursos da máquina, processamento e memória, para executar alguma tarefa, mas não consegue, normalmente porque os recursos já estão alocados por outra tarefa.
Minha recomendação inicial é verificar o arquivo de configuração do mysql: no Debian, o caminho para o arquivo é /etc/mysql/my.cnf
Verifique qual o tamanho alocado para as linhas key_buffer, query_cache_limit e query_cache_size. Aqui no ministério, em uma máquina com cerca de 19GB de RAM, estamos usando 512M, 64M e 512M, respectivamente, sem qualquer gargalo. Após realizar essas modificações, será necessário reiniciar o serviço mysql para que a máquina realoque o espaço adequado.
Att,
Em 01/08/2017 09:01:55, Cleber Franco escreveu:que está incorreta? Estamos com o MySQL (PerconaDB).>AS publicacao,publicacao.numero,> publicacao.id_veiculo_io AS idveiculoio,publicacao.dta_> publicacao_io AS publicacaoio,publicacao.> pagina_io AS paginaio,veiculo_imprensa_> nacional.sigla AS siglaveiculoimprensanacional,> secao_imprensa_nacional.nome AS nomesecaoimprensanacional
FROM publicacao INNER JOIN veiculo_publicacao ON publicacao.id_veiculo_> publicacao=veiculo_publicacao.> id_veiculo_publicacao LEFT JOIN veiculo_imprensa_nacional ON publicacao.id_veiculo_io=> veiculo_imprensa_nacional.id_> veiculo_imprensa_nacional LEFT JOIN secao_imprensa_nacional
ON publicacao.id_secao_io=secao_> imprensa_nacional.id_secao_> imprensa_nacional WHERE publicacao.id_documento=12335Arthur Colombo Duarte
Administrador de Bancos de Dados
CGMI - Coordenação Geral de Modernização em Informática
Ministério das Cidades
Telefone: (61) 2108-1160 -
29 de Agosto de 2017 às 13:35Alguma instituição que usa banco de dados Oracle tem esses erros de “lock”/”deadlock” nos seus logs ?
Obrigado.De: sei-tecnico [mailto:sei-tecnico-bounces@listas.softwarepublico.gov.br] Em nome de Cristiano José Müller
Enviada em: sexta-feira, 21 de julho de 2017 13:37
Para: Guilherme Marques Amaral de Campos
Assunto: {Spam?} [sei-tecnico] RES: Re: RES: Deadlock no SEIcristiano.muller@procempa.com.brPara: Guilherme Andrade Del Cantoni[cid:image001.jpg@01D320B2.79678010]MailScanner detectou uma possível tentativa de fraude de "www.museus.gov.br" passando-se por https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/sei-tecnico -
1 de Setembro de 2017 às 13:24Cristiano,
O Ibama usa SEI v3 com Oracle e nunca tivemos este erro no log.Felipe Ventorim Rodrigues Paulin
Analista Administrativo
Coordenação de Sistemas de Informação - CSI/CGTI/Ibama
Email: felipe.paulin@ibama.gov.br
Telefone: 61 3316-1053
Em 29/08/2017 10:35, Cristiano José Müller escreveu:Felipe Ventorim Rodrigues Paulin
Analista Administrativo
Coordenação de Sistemas de Informação - CSI/CGTI/Ibama
Email: felipe.paulin@ibama.gov.br
Telefone: 61 3316-1053
João Lemgruber
Douglas Dias
Guilherme Del Cantoni
Guilherme Campos
Cristiano José Müller
Felipe Paulin