Início / dba / 问题

Perguntas[replication](dba)

Martin Hope
KMT
Asked: 2025-03-15 12:14:06 +0800 CST
  • 7

Estamos no processo de atualização de nossa rede MariaDB 10.1 Master-Slave para MariaDB 10.11. Estamos conduzindo-os em 2 estágios - atualizar todos os escravos para v10.11 e, em um dia posterior, introduzir um novo mestre com v10.11.

O aplicativo é totalmente compatível com a nova versão e não há problemas. Eu estava configurando novos escravos de produção (v10.11) na mesma rede, com o mesmo tipo de instância Linode (50 vcpu, 128 GB de RAM) da produção. O tamanho do banco de dados é de aproximadamente 500 GB.

Novas instâncias v10.11 têm as mesmas configurações do InnoDB que os outros escravos v10.1. innodb_buffer_pool_size=100G para todas as instâncias. Ao iniciar a replicação, o lag continua crescendo nessas instâncias. Percebi que a CPU delas está abaixo de 50% com consultas/segundo menores que 4k. Quando geralmente há um lag na versão mais antiga (v10.1), sua CPU geralmente está acima de 120% com consultas/segundo acima de 15k e ela alcançará o mestre em poucos minutos.

seconds_behind_master na v10.11 se tornou quase 3-4 dias. Em um dos novos escravos, aumentei o slave_parallel_thread=12 e isso melhorou. Sua CPU chegou a cerca de 300% com consultas / segundo com média de cerca de 20k. Mas a outra v10.11 com slave_parallel_therads=0, ainda está alguns dias atrás do Master. Não está utilizando totalmente a CPU - apenas 40-50% da CPU. As consultas por segundo estão abaixo de 4k. Os escravos MariaDB v10.1 estão sendo executados com slave_parallel_threads=0 e nunca experimentei esse longo atraso com eles. Como eu disse, o atraso geralmente se instala em poucos minutos.

Tenho tentado ajustar algumas configurações, reiniciar os escravos algumas vezes, reconstruir os escravos, mas sem sucesso.

Algumas perguntas/preocupações -

  1. Por que o MariaDB 10.1 tem melhor desempenho na replicação com melhor eficiência do que o novo MariaDB 10.11. v10.1 - não tem slave_parallel_threads habilitado
  2. A utilização da CPU é muito menor na nova versão 10.11 do que na versão 10.1 com melhores consultas / segundo

Alguém já passou por isso antes?

Todos os escravos (v10.1 e v10.11) têm essas configurações -

wait_timeout = 60
interactive_timeout = 60

max_connections = 1000

innodb_buffer_pool_size = 100G
max_allowed_packet = 1G

innodb_strict_mode=OFF
sql_mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

innodb_data_file_path=ibdata1:500M:autoextend

read_rnd_buffer_size = 256M
sort_buffer_size = 256M
join_buffer_size = 256M

tmp_table_size= 1536M
max_heap_table_size= 1536M

skip_slave_start
slave-type-conversions=ALL_NON_LOSSY

read_buffer_size = 20M
#innodb_additional_mem_pool_size = 256M

innodb_log_file_size = 1G
innodb_buffer_pool_instances = 40
skip_name_resolve = 1

tmp_table_size= 1536M
max_heap_table_size= 1536M

server_id=114
#slave-type-conversions=ALL_NON_LOSSY

max_connect_errors = 1000000
log_warnings = 2

####
read_buffer_size = 20M
#innodb_additional_mem_pool_size = 256M

query_cache_type=0

Diagrama de configuração

replication
Martin Hope
Areeb
Asked: 2024-11-14 19:37:55 +0800 CST
  • 4

Estou tentando configurar uma réplica primária-secundária. Isso é para fazer uma migração sem tempo de inatividade do primeiro nó para o segundo nó nos próximos dias.

O nó primário foi configurado, a configuração foi atualizada, adicionei o keyfile. Fiz o mesmo com o nó secundário.

Também inicializei a replicação, adicionei o nó secundário à replicação. Posso ver um ping e uptime, mas o nó secundário está preso em “STARTUP”.

No entanto, não há configuração de réplica no nó secundário. Além disso, ele está vomitando isso em todo o log de erros repetidamente.

Nó Secundário (Logs):

{"t":{"$date":"2024-11-14T11:35:14.018+00:00"},"s":"I",  "c":"CONNPOOL", "id":22576,   "ctx":"ReplNetwork","msg":"Connecting","attr":{"hostAndPort":"Ubuntu-2204-jammy-amd64-base:27017"}}
{"t":{"$date":"2024-11-14T11:35:14.818+00:00"},"s":"W",  "c":"SHARDING", "id":7012500, "ctx":"QueryAnalysisConfigurationsRefresher","msg":"Failed to refresh query analysis configurations, will try again at the next interval","attr":{"error":"PrimarySteppedDown: No primary exists currently"}}
{"t":{"$date":"2024-11-14T11:35:15.000+00:00"},"s":"W",  "c":"QUERY",    "id":23799,   "ctx":"ftdc","msg":"Aggregate command executor error","attr":{"error":{"code":26,"codeName":"NamespaceNotFound","errmsg":"Unable to retrieve storageStats in $collStats stage :: caused by :: Collection [local.oplog.rs] not found."},"stats":{},"cmd":{"aggregate":"oplog.rs","cursor":{},"pipeline":[{"$collStats":{"storageStats":{"waitForLock":false,"numericOnly":true}}}],"$db":"local"}}}
{"t":{"$date":"2024-11-14T11:35:15.000+00:00"},"s":"W",  "c":"QUERY",    "id":23799,   "ctx":"ftdc","msg":"Aggregate command executor error","attr":{"error":{"code":26,"codeName":"NamespaceNotFound","errmsg":"Unable to retrieve storageStats in $collStats stage :: caused by :: Collection [config.transactions] not found."},"stats":{},"cmd":{"aggregate":"transactions","cursor":{},"pipeline":[{"$collStats":{"storageStats":{"waitForLock":false,"numericOnly":true}}}],"$db":"config"}}}
{"t":{"$date":"2024-11-14T11:35:15.001+00:00"},"s":"W",  "c":"QUERY",    "id":23799,   "ctx":"ftdc","msg":"Aggregate command executor error","attr":{"error":{"code":26,"codeName":"NamespaceNotFound","errmsg":"Unable to retrieve storageStats in $collStats stage :: caused by :: Collection [config.image_collection] not found."},"stats":{},"cmd":{"aggregate":"image_collection","cursor":{},"pipeline":[{"$collStats":{"storageStats":{"waitForLock":false,"numericOnly":true}}}],"$db":"config"}}}
{"t":{"$date":"2024-11-14T11:35:15.018+00:00"},"s":"I",  "c":"CONNPOOL", "id":22576,   "ctx":"ReplNetwork","msg":"Connecting","attr":{"hostAndPort":"Ubuntu-2204-jammy-amd64-base:27017"}}
{"t":{"$date":"2024-11-14T11:35:16.000+00:00"},"s":"W",  "c":"QUERY",    "id":23799,   "ctx":"ftdc","msg":"Aggregate command executor error","attr":{"error":{"code":26,"codeName":"NamespaceNotFound","errmsg":"Unable to retrieve storageStats in $collStats stage :: caused by :: Collection [local.oplog.rs] not found."},"stats":{},"cmd":{"aggregate":"oplog.rs","cursor":{},"pipeline":[{"$collStats":{"storageStats":{"waitForLock":false,"numericOnly":true}}}],"$db":"local"}}}
{"t":{"$date":"2024-11-14T11:35:16.000+00:00"},"s":"W",  "c":"QUERY",    "id":23799,   "ctx":"ftdc","msg":"Aggregate command executor error","attr":{"error":{"code":26,"codeName":"NamespaceNotFound","errmsg":"Unable to retrieve storageStats in $collStats stage :: caused by :: Collection [config.transactions] not found."},"stats":{},"cmd":{"aggregate":"transactions","cursor":{},"pipeline":[{"$collStats":{"storageStats":{"waitForLock":false,"numericOnly":true}}}],"$db":"config"}}}
{"t":{"$date":"2024-11-14T11:35:16.001+00:00"},"s":"W",  "c":"QUERY",    "id":23799,   "ctx":"ftdc","msg":"Aggregate command executor error","attr":{"error":{"code":26,"codeName":"NamespaceNotFound","errmsg":"Unable to retrieve storageStats in $collStats stage :: caused by :: Collection [config.image_collection] not found."},"stats":{},"cmd":{"aggregate":"image_collection","cursor":{},"pipeline":[{"$collStats":{"storageStats":{"waitForLock":false,"numericOnly":true}}}],"$db":"config"}}}
{"t":{"$date":"2024-11-14T11:35:16.018+00:00"},"s":"I",  "c":"CONNPOOL", "id":22576,   "ctx":"ReplNetwork","msg":"Connecting","attr":{"hostAndPort":"Ubuntu-2204-jammy-amd64-base:27017"}}

rs.config() no primário

{
  set: 'rs0',
  date: ISODate('2024-11-14T11:36:01.498Z'),
  myState: 1,
  term: Long('3'),
  syncSourceHost: '',
  syncSourceId: -1,
  heartbeatIntervalMillis: Long('2000'),
  majorityVoteCount: 1,
  writeMajorityCount: 1,
  votingMembersCount: 1,
  writableVotingMembersCount: 1,
  optimes: {
    lastCommittedOpTime: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
    lastCommittedWallTime: ISODate('2024-11-14T11:36:01.474Z'),
    readConcernMajorityOpTime: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
    appliedOpTime: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
    durableOpTime: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
    writtenOpTime: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
    lastAppliedWallTime: ISODate('2024-11-14T11:36:01.474Z'),
    lastDurableWallTime: ISODate('2024-11-14T11:36:01.474Z'),
    lastWrittenWallTime: ISODate('2024-11-14T11:36:01.474Z')
  },
  lastStableRecoveryTimestamp: Timestamp({ t: 1731584157, i: 2 }),
  electionCandidateMetrics: {
    lastElectionReason: 'electionTimeout',
    lastElectionDate: ISODate('2024-11-14T09:11:55.719Z'),
    electionTerm: Long('3'),
    lastCommittedOpTimeAtElection: { ts: Timestamp({ t: 0, i: 0 }), t: Long('-1') },
    lastSeenWrittenOpTimeAtElection: { ts: Timestamp({ t: 1731575489, i: 10 }), t: Long('2') },
    lastSeenOpTimeAtElection: { ts: Timestamp({ t: 1731575489, i: 10 }), t: Long('2') },
    numVotesNeeded: 1,
    priorityAtElection: 1,
    electionTimeoutMillis: Long('10000'),
    numCatchUpOps: Long('0'),
    newTermStartDate: ISODate('2024-11-14T09:11:55.790Z'),
    wMajorityWriteAvailabilityDate: ISODate('2024-11-14T09:11:55.803Z')
  },
  members: [
    {
      _id: 0,
      name: 'Ubuntu-2204-jammy-amd64-base:27017',
      health: 1,
      state: 1,
      stateStr: 'PRIMARY',
      uptime: 8656,
      optime: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
      optimeDate: ISODate('2024-11-14T11:36:01.000Z'),
      optimeWritten: { ts: Timestamp({ t: 1731584161, i: 5 }), t: Long('3') },
      optimeWrittenDate: ISODate('2024-11-14T11:36:01.000Z'),
      lastAppliedWallTime: ISODate('2024-11-14T11:36:01.474Z'),
      lastDurableWallTime: ISODate('2024-11-14T11:36:01.474Z'),
      lastWrittenWallTime: ISODate('2024-11-14T11:36:01.474Z'),
      syncSourceHost: '',
      syncSourceId: -1,
      infoMessage: '',
      electionTime: Timestamp({ t: 1731575515, i: 1 }),
      electionDate: ISODate('2024-11-14T09:11:55.000Z'),
      configVersion: 10,
      configTerm: 3,
      self: true,
      lastHeartbeatMessage: ''
    },
    {
      _id: 1,
      name: 'XXXXXXXXXXXXXXX:27017',
      health: 1,
      state: 0,
      stateStr: 'STARTUP',
      uptime: 1925,
      optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long('-1') },
      optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long('-1') },
      optimeWritten: { ts: Timestamp({ t: 0, i: 0 }), t: Long('-1') },
      optimeDate: ISODate('1970-01-01T00:00:00.000Z'),
      optimeDurableDate: ISODate('1970-01-01T00:00:00.000Z'),
      optimeWrittenDate: ISODate('1970-01-01T00:00:00.000Z'),
      lastAppliedWallTime: ISODate('1970-01-01T00:00:00.000Z'),
      lastDurableWallTime: ISODate('1970-01-01T00:00:00.000Z'),
      lastWrittenWallTime: ISODate('1970-01-01T00:00:00.000Z'),
      lastHeartbeat: ISODate('2024-11-14T11:36:00.038Z'),
      lastHeartbeatRecv: ISODate('1970-01-01T00:00:00.000Z'),
      pingMs: Long('9'),
      lastHeartbeatMessage: '',
      syncSourceHost: '',
      syncSourceId: -1,
      infoMessage: '',
      configVersion: -2,
      configTerm: -1
    }
  ],
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1731584161, i: 5 }),
    signature: {
      hash: Binary.createFromBase64('XXXXXXXXXX', 0),
      keyId: Long('XXXXXXXXXXXX')
    }
  },
  operationTime: Timestamp({ t: 1731584161, i: 5 })
}

rs.config() no Secundário

MongoServerError[NotYetInitialized]: no replset config has been received
replication
Martin Hope
Yossi Geretz
Asked: 2024-05-15 03:47:53 +0800 CST
  • 6

Tenho um banco de dados primário no nível de serviço Premium.

insira a descrição da imagem aqui

Estou tentando criar uma segunda réplica geográfica para uma região diferente. O primário está na Costa Leste, a primeira réplica está no Centro-Sul e agora estou tentando criar uma segunda réplica no Oeste 2.

A literatura afirma que posso criar até quatro réplicas para um único primário. (Vi referências ao fato de que isso requer nível de serviço Premium, por isso aumentei o banco de dados para o nível Premium.)

https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview?view=azuresql#configurando-secondary-database

Até quatro geosecundários podem ser criados para um primário. Se houver apenas um secundário e ele falhar, o aplicativo estará exposto a um risco maior até que um novo secundário seja criado. Se existirem vários secundários, o aplicativo permanecerá protegido mesmo se um dos secundários falhar. Secundários adicionais também podem ser usados ​​para expandir cargas de trabalho somente leitura.

Criei minha primeira réplica e agora estou tentando criar a segunda réplica em uma região diferente, é claro. Estou recebendo consistentemente o mesmo erro:

Limite de replicação atingido. O banco de dados 'teste' não pode ter mais de 1 relacionamento de replicação. (Código: GeoReplicaLimitReached)

Não pode ter mais de um relacionamento de replicação? Mas a literatura diz que eu deveria poder ter até quatro?

Aqui está um instantâneo mais completo da configuração do banco de dados.

insira a descrição da imagem aqui

Obrigada pelo Conselho!

replication
Martin Hope
Yossi Geretz
Asked: 2024-04-13 03:10:45 +0800 CST
  • 5

Estou tentando usar as instruções aqui -

https://learn.microsoft.com/en-US/troubleshoot/sql/database-engine/security/transfer-logins-passwords-between-instances

para copiar logins entre o servidor que hospeda meu banco de dados primário e o servidor que hospeda minha réplica de leitura. Isso é importante para mim porque quero que todos os meus usuários que estão atualmente consultando o banco de dados de produção comecem a consultar a réplica de leitura.

Consigo criar os sprocs no banco de dados master do servidor primário, mas quando tento executar o sproc, conforme as instruções, recebo o seguinte erro:

EXEC sp_help_revlogin

Msg 229, Nível 14, Estado 5, Procedimento sp_help_revlogin, Linha 1 [Batch Start Line 0] A permissão EXECUTE foi negada no objeto 'sp_help_revlogin', banco de dados 'master', esquema 'dbo'.

insira a descrição da imagem aqui

Como faço para superar isso?

Estou usando o banco de dados SQL hospedado do Azure e estou conectado ao servidor como administrador (usando a conta definida como Microsoft Entra Admin).

Obrigada pelo Conselho!

replication
Martin Hope
Yossi Geretz
Asked: 2024-04-12 06:51:29 +0800 CST
  • 6

Eu tenho um banco de dados chamado myAppDB em um SQL Server hospedado no Azure no Datacenter do Leste dos EUA. Criei um novo SQL Server no datacenter Centro-Sul dos EUA. Em seguida, criei uma réplica geográfica do myAppDB no servidor no leste dos EUA para o servidor no centro-sul dos EUA. Funcionou! Validei que o novo banco de dados é de fato somente leitura do SSMS e que os dados estão sendo bombeados à medida que o banco de dados primário é atualizado com transações em andamento.

O problema é que a interface do Azure para criar a réplica não permite a especificação do nome do banco de dados para a réplica.

insira a descrição da imagem aqui

Agora tenho dois bancos de dados diferentes em dois servidores diferentes, ambos com o mesmo nome - myAppDB . Fisicamente isso funciona, mas em termos de usabilidade, se estou trabalhando no SSMS com duas conexões de servidor de banco de dados, é confuso porque independente de qual banco de dados estou acessando, o SSMS reporta myAppDB . Prefiro que a réplica tenha um nome como myAppDB_Read apenas para trazer um pouco mais de clareza ao meu ambiente de trabalho. Existe alguma maneira de conseguir isso? (Já tentei o método padrão para renomear um banco de dados, mas recebi uma mensagem de erro informando que a operação não pode ser executada porque o banco de dados está em um relacionamento de replicação.)

Obrigada pelo Conselho!

replication
Martin Hope
Furkan YIlmaZ
Asked: 2024-04-01 16:56:25 +0800 CST
  • 5

Criei um cluster com dois fragmentos. Ou assim pensei. No meu projeto, o primeiro servidor possui mongos_router shard1 (3 nós) e servidores de configuração. O segundo servidor possui apenas 2 nós de fragmento. Depois de configurar os shards, habilitei o sharding para cada banco de dados. E quando olho a saída de sh.status() vejo a saída abaixo:

...
  {
    database: {
      _id: 'wins_emission',
      primary: 'shard1rs',
      partitioned: false,
      version: {
        uuid: UUID('aebf94cf-6069-41ba-9a91-f91a944071b1'),
        timestamp: Timestamp({ t: 1711952615, i: 3000 }),
        lastMod: 1
      }
    },
    collections: {}
  },
  {
    database: {
      _id: 'wins_healthcheck',
      primary: 'shard2rs',
      partitioned: false,
      version: {
        uuid: UUID('663cb5f7-b7b3-4f40-9f52-2c3d1969fb65'),
        timestamp: Timestamp({ t: 1711952305, i: 4 }),
        lastMod: 1
      }
    },
...

Eu entendi isso porque os bancos de dados serão distribuídos entre os fragmentos. E eu esperava que os dados entre os nós não fossem iguais. Por exemplo, a tabela de notificações tem 17,7 mil documentos. E espero que esses documentos sejam compartilhados entre os nós. Como o primeiro nó do shard1 tem 4k, o nó do segundo shard1 tem 4k etc. Cada nó em cada fragmento tem a mesma quantidade de 17,7k. Posso estar sendo mal interpretado.

Tentei fragmentar no nível da coleção para a tabela de notificações. Eu criei uma chave de fragmento com hash. E então executou sh.shardCollection()o comando. E agora meu primeiro shard tem 4,7 mil documentos entre seus próprios nós, enquanto o shard2 tem 12,9 mil em si. Agora, isso me fez pensar nessas questões.

  1. Preciso fragmentar todas as coleções para usar um cluster fragmentado?
  2. Devo fragmentar todas as coleções ou apenas aquelas que contêm grandes dados, como logs.
  3. Por que todos os nós em um fragmento têm a mesma quantidade de documentos? Eles não deveriam distribuir os dados por si só?

Qualquer ajuda é apreciada.

Edição 1: Saída do getShardDistribution de uma coleção específica;

{
  data: '382.25MiB',
  docs: 7006,
  chunks: 3,
  'estimated data per chunk': '127.41MiB',
  'estimated docs per chunk': 2335
}
---
Shard shard2rs at shard2rs/172.16.114.129:27020,172.16.114.129:27021,172.16.114.129:27022
{
  data: '579.78MiB',
  docs: 10578,
  chunks: 1,
  'estimated data per chunk': '579.78MiB',
  'estimated docs per chunk': 10578
}
---
Totals
{
  data: '962.03MiB',
  docs: 17584,
  chunks: 4,
  'Shard shard1rs': [
    '39.73 % data',
    '39.84 % docs in cluster',
    '55KiB avg obj size on shard'
  ],
  'Shard shard2rs': [
    '60.26 % data',
    '60.15 % docs in cluster',
    '56KiB avg obj size on shard'
  ]
}
replication
Martin Hope
Andrei Hristov
Asked: 2024-01-24 16:38:14 +0800 CST
  • 5

Estou executando uma replicação multimestre de 3 servidores mestres para 1 escravo. Cada um dos mestres possui 2 bancos de dados, mas estou replicando apenas 1 dos bancos de dados.

Versão do servidor: 8.0.35-0ubuntu0.20.04.1 (Ubuntu)

A replicação está funcionando bem, mas minha pergunta é: por que quando executo o

show replica status \G

Não vejo os parâmetros que defini para Replicate_Do_DB ou replicate-wild-do-table por canal no relatório de status. Se eu defini-los como globais (sem especificar um canal), eles aparecem no relatório, mas não quando definidos por canal, alguma ideia do porquê disso?

Isto é extraído do arquivo de configuração do MySQL ( /etc/mysql/mysql.conf.d/mysqld.cnf ):

master-info-repository=table
relay-log-info-repository=table

replicate-wild-do-table='src3_s#####':s#####v.%
replicate-wild-do-table='src2_b#####':b#####v.%
replicate-wild-do-table='src1_d#####':d#####v.%

e este é o resultado do 'show replication status \G':

mysql> show replica status \G
*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 101.114.110.113
                  Source_User: slave_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql###-bin.001307
          Read_Source_Log_Pos: 85496
               Relay_Log_File: plfamily-replication-slave-relay-bin-src1_#####.000086
                Relay_Log_Pos: 323
        Relay_Source_Log_File: mysql###-bin.001307
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: 
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 85496
              Relay_Log_Space: 86304
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 1
                  Source_UUID: a604d2af-ed30-11ea-a99d-8657a156e939
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Source_Retry_Count: 86400
                  Source_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Source_SSL_Crl:
           Source_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: src1_d######
           Source_TLS_Version:
       Source_public_key_path:
        Get_Source_public_key: 0
            Network_Namespace:
*************************** 2. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 237.239.251.262
                  Source_User: slave_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql###-bin.000002
          Read_Source_Log_Pos: 45872
               Relay_Log_File: plfamily-replication-slave-relay-bin-src2_#####.000029
                Relay_Log_Pos: 326
        Relay_Source_Log_File: mysql###-bin.000002
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: 
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 45872
              Relay_Log_Space: 921
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 3
                  Source_UUID: ab801adf-ddb3-11eb-96b2-a27c967973a1
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Source_Retry_Count: 86400
                  Source_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Source_SSL_Crl:
           Source_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: src2_b#####
           Source_TLS_Version:
       Source_public_key_path:
        Get_Source_public_key: 0
            Network_Namespace:
*************************** 3. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 134.148.228.213
                  Source_User: slave_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql####-bin.000002
          Read_Source_Log_Pos: 47931
               Relay_Log_File: plfamily-replication-slave-relay-bin-src3_s####.000025
                Relay_Log_Pos: 328
        Relay_Source_Log_File: mysql####-bin.000002
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: 
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 47931
              Relay_Log_Space: 925
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 4
                  Source_UUID: ab801adf-ddb3-11eb-96b2-a27c967973a1
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Source_Retry_Count: 86400
                  Source_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Source_SSL_Crl:
           Source_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: src3_s######
           Source_TLS_Version:
       Source_public_key_path:
        Get_Source_public_key: 0
            Network_Namespace:
3 rows in set (0.00 sec)
replication
Martin Hope
Rafael
Asked: 2023-06-12 22:03:51 +0800 CST
  • 5

Estou tendo problemas para entender como o replicaSet funciona usando 2 nós e um árbitro, usando a comunidade MongoDB 6 em 3 servidores com ubuntu 22.04.

Meu cenário atual é que tenho 2 servidores em um replicaSet onde o primeiro é primário (prioridade 1) e um secundário com prioridade 0,5 (eu configurei assim, então sempre poderia ter o primário como servidor principal). Um terceiro servidor não armazena nenhum dado funcionando como árbitro.

Testei desligar meu primário, então meu secundário foi eleito como primário sem nenhum problema. Mas se eu tentar gravar qualquer dado nele, ele não salva até que meu primário volte.

A ideia é ter meu secundário como um servidor sobressalente caso meu principal falhe por qualquer motivo, para que meus aplicativos possam continuar salvando e lendo.

Eu sei que poderia usar 3 nós de servidor, então eu teria 2 servidores graváveis ​​para votar, mas considerando que esse banco de dados terá cerca de 1 TB de dados, não posso ter um terceiro servidor salvando a mesma quantidade de dados por enquanto.

Eu tentei alguns comandos sobre a preocupação de gravação, mas tive dois comportamentos diferentes:

1 - Usando este comando, usando mongodb Compass, parece gravar novos dados, mas não é listado até que o primário volte:

db.adminCommand({ "setDefaultRWConcern": 1, "defaultWriteConcern": { "w": 1 } })

2 - Usando mongodb Compass, mostre "Iinserting Document", mas nunca termine, até que o primário volte:

db.adminCommand({ "setDefaultRWConcern": 1, "defaultWriteConcern": { "w": "majority" } })

Atualização de como conectado: Por meio de um aplicativo PHP, usando ssh com mongoshMongoDB Compass com string de conexão (com ajuda de Wernfried): mongodb://rootuser:rootpasswd@primaryip:27017,secondaryip:27017/?replicaSet=myRepl&authSource=admin&readPreference=primaryPreferred

Se eu desligar meu servidor primário, o secundário é eleito como primário, mas não posso escrever até que ambos os nós estejam online.

É assim que meu rs.conf() está agora

{
   _id: 'rspd01',
   version: 13,
   term: 51,
   members: [
     {
        _id: 0,
        host: 'primaryIP:27017',
        arbiterOnly: false,
        buildIndexes: true,
        hidden: false,
        priority: 1,
        tags: {},
        secondaryDelaySecs: Long("0"),
        votes: 1
     },
     {
        _id: 1,
        host: 'secondaryIP:27017',
        arbiterOnly: false,
        buildIndexes: true,
        hidden: false,
        priority: 0.5,
        tags: {},
        secondaryDelaySecs: Long("0"),
        votes: 1
     },
     {
        _id: 2,
        host: 'arbiterIP:27017',
        arbiterOnly: true,
        buildIndexes: true,
        hidden: false,
        priority: 0,
        tags: {},
        secondaryDelaySecs: Long("0"),
        votes: 1
     }
   ],
   protocolVersion: Long("1"),
   writeConcernMajorityJournalDefault: true,
   settings: {
      chainingAllowed: true,
      heartbeatIntervalMillis: 2000,
      heartbeatTimeoutSecs: 10,
      electionTimeoutMillis: 10000,
      catchUpTimeoutMillis: -1,
      catchUpTakeoverDelayMillis: 30000,
      getLastErrorModes: {},
      getLastErrorDefaults: { w: 1, wtimeout: 0 },
      replicaSetId: ObjectId("64863fd09a9b54d4cd0da913")
   }
}

Existe algum comando que eu possa fazer para trabalhar com essa estrutura?

Atenciosamente.

replication