MyISAM may the main problem. Any write (including replication writes) to a table blocks all other writes and, to some extent, even reads. Hence, the "parallel" replication threads are sometimes blocking each other. And even SELECTs on the Replica are blocked and/or block replication. I strongly encourage you to switch to InnoDB, then come back if you still have issues. InnoDB transactions and replication are better kept in order even without completely stalling other replication threads.

database system is ready to accept connections Exactly accept connections, not database system is ready to accept read only connections Which means you started a new primary server, not replication. Also there was no entering standby mode message. You need to make another base backup and start https://www.postgresql.org/docs/13/hot-standby.html : put empty standby.signal file in the data directory. pg_basebackup with option -R can place this file and write corresponding primary_conninfo to postgresql.auto.conf

Yes, that's possible however you need to ensure that no full backup runs in between your last full backup and the current differential backup. If full backup runs then it should be copy only. Whenever you take full backup, the successive differential backup gets linked with that. Differential backup contains all the changes done from last full backup. So, if you have multiple differential backup after last full backup, you need to consider only the last one and not previous ones. Below image from https://www.sqlshack.com/understanding-sql-server-backup-types/ helps in understanding:

You need to perform a https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-BASE-BACKUP regularly, since you need to restore the backup before you can https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-PITR-RECOVERY .

Yes. Every update will be transferred, even with the same value. The https://www.postgresql.org/docs/current/app-pgrecvlogical.html (builtin program) can be used to prove behavior: pg_recvlogical --start -f /tmp/recvlog --slot=logical1 --create-slot -d postgres --plugin=pgoutput --if-not-exists --option='proto_version=2' --option='publication_names=am_pub' --option='binary=false' (multiline formatting for a better looking response) Repeated invocation of the query update am set k = 'hi' where n = 2; with the same arguments will write the passed data to /tmp/recvlog, for example: U@Nthit2.00 CQNQN0z���� Note that publishing uses the binary data protocol, and pg_recvlogical does not decode specific messages. But it's enough to check if data is being sent through the publication on updates of identical values.

Someone helped me on the Postgres community for this one, so answering it here. The target DB was lacking enough max_logical_replication_workers. Since I already had 2 subscriptions going and the max_logical_replication_workers on the target DB was set to 2. So when I started the second subscription with copy_data=true, it wasn't able to start the temporary subscription for copying the data from the source. That is why it was stuck in the initialize phase. To rectify it, I increased the max_logical_replication_workers to 4 on the target DB. This needs a DB restart, so please note, that you will have to restart the receiving database. And voila! it worked. targetdb=# show max_logical_replication_workers ; max_logical_replication_workers --------------------------------- 4 (1 row) Please see that I was missing this WARNING in the log file. "WARNING,53400,"out of logical replication worker slots",,"You might need to increase max_logical_replication_workers.",,,,,,,"","logical replication worker" So please look out for such an error on your log files if you face this error.

Replication always has lag, if only a very small amount, because your data changes are not even written to the binary log until you commit a transaction. Then the replica has to download those events in the binary log and apply them on the replica instance. This is normally very quick, but by definition, it is > 0 lag for every event. It is also possible for your application to attempt to read data it just wrote, before it commits its own transaction. In that case, there's no way the replica can have the same change, since it hasn't even been committed on the source instance yet. If your app needs absolutely current data, with no possibility of reading stale data, then the queries must read from the source instance, not a replica. But not every read needs to read such strictly current data. Each query in your application has potentially different sensitivity to reading data that is lagging a little bit behind the source. I wrote a presentation https://www.percona.com/resources/technical-presentations/readwrite-splitting-mysql-and-php-percona-mysql-webinars for Percona, which describes several different solutions for different levels of replication lag tolerance.

Your master is only binary logging alpha database changes and your slave is only applying changes to database beta. Because the binary log is filtered to include only alpha, there won't be any beta changes there for the slave to apply. Recommending avoiding all replication filtering unless you have a specific need. If you do have a need, recommend binlog_format=ROW to ensure things are always saved. See https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#option_mysqld_binlog-do-db for details.

It ends up that I did a test restoration in the past on a new db instance, without removing the archive_command in the postgresql.conf file, which ended up archiving that 0000007.history empty timeline. So, when a new server was trying to fetch the archived logs from the barman, it would find that dummy timeline 0000007.history file, but without actual xlogs in the barman server, leading up to the generated error logs above. Solution: Connect to the barman server. Manually moving the 0000007.history file. Manually removing the 00000007.history line in the xlog.db on the barman server wals/ directory. Restart the postgres on the secondary. Advise: Take backup of anything you change in the barman server before doing it.

I recommend you enable log_slave_updates on both of your masters. Then they will add the replicated changed to their own binary log, so both instances' binary logs will have all changes. Then you don't need multi-master replication. See https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#log_slave_updates

express does not support FCI. I think the meaning of any means any production edition and this is not express, usually. sql server express support replication as subscriber only: https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-version-15?view=sql-server-ver15#Replication About failover, you can't fail over on subcriber-only members and, in the case you are studing, HA is reached with the help of Availability Groups. So definitely throw away sql express to have better options for HA and DR.

As user changing SQL like ALTER USER etc is replicated as a statement, to prevent the replication of those, use SET SQL_LOG_BIN=0 in the session where the SQL is executed. Sorry, replication filtering won't help. ref: https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#sql_log_bin .

This might not work in your case, but it did work in my case.... First check that nobody is in the distribution database with: SELECT * FROM sys.dm_exec_sessions AS sdes WHERE sdes.database_id = DB_ID('distribution'); If you find (a) session(s) in the database, then kill them with: KILL ; Next drop the distribution database: EXEC sp_dropdistributiondb @database = N'distribution'; Then deactivate the distributor with: EXEC sp_dropdistributor; If the above command fails run: EXEC sp_dropdistributor @ignore_distributor = 1, @no_checks = 1; Reference: https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-dropdistributiondb-transact-sql?view=sql-server-ver15 (Microsoft | SQL Docs)

If you use localhost 127.0.0.1 address and want to have replica set, then all (different) replicas (mongoD processes) must exist at different ports AND have different data directories (storage.dbPath), because they are at the same machine. So, rs0 uses f.ex. 27007, rs1 uses f.ex. 27017, rs2 uses f.ex. 27027 and then directories are f.ex. /var/lib/mongodb/rs0, /var/lib/mongodb/rs1... However, if you build your replica set with multiple machines, then you cannot use localhost address, you need to bind to the network card IP port can be 27017 at every node

It turned out to be a VMWare setting issue. From what the tech explained to me, they were letting the old packets/connections to reconnect instead of letting it make a new connection. Thats why MySQL was unable to "see" any new data.

Replication maintains synchronization of the data. It does not initialize the Repicas. That is, you must first copy the data from the Primaries to the Replica, then establish the "multi-source" replication. If writes (to the Primaries) are happening during the setup, it gets tricky to avoid losing them.

No, that won't help at all. You have three alternative options: increase wal_keep_size to a big enough value That is a simple, but coarse solution, in that it makes the primary always retain a certain amount of WAL, regardless if it is too much or not enough (because the downtime is longer than expected). set a restore_command on the, so that it can use the WAL archive to catch up That may be the best option if you have a WAL archive. use a physical replication slot Such an object marks a certain position in the WAL stream and prevents the primary from discarding WAL that is still needed by the standby. While being an elegant solution, this bears the risk of breaking the primary if the standby stays down too long. Consequently, it is a good idea to monitor replication in this case and/or to set max_slot_wal_keep_size to put a cap on the amount of WAL retained on the primary.

Is there anyway to recover the slave, to get back to sync ? No, unless you have archive WAL of all segments between current standby and primary server Or is there anyway to re-create the slave without stop the running master? Just simple native https://www.postgresql.org/docs/current/app-pgbasebackup.html command. stop current replica remove datadir (and tablespaces if any) on replica run pg_basebackup with appropriate oprions (typically I use -R -X stream -c fast -P -U -h source_addr, -R is mandatory to start replica, not new primary) start DB and watch its logs

If you want an actual replication solution for this, then you can use multi-source replication. See the https://mariadb.com/kb/en/multi-source-replication/ and this https://mariadb.com/resources/blog/high-availability-with-multi-source-replication-in-mariadb-server/ for details and examples. As for using mariabackup as part of this, I suppose it could make sense for the initial provisioning of the server. I don't have experience with restoring multiple such backups to one MariaDB server, but I think it can be done. You may want to perform partial mariabackups of the source databases (so you exclude the system schemas/tables), and then restoring can possibly be done one backup at a time, either with mariabackup's --copy-back option or by manually copying the table files. You probably don't want to use mariabackup as a full-time replication solution, amongst other reasons because it does briefly lock your database while the backup is running.

Initially there's a copy of the master on the lines. If you're going to rejoin the empty base, the replication will be broken quite quickly, as the necessary data will not be found to meet the blog requests. The construction of the line suggests that you're not just copying the data from the master, but you're also very accurately displaying the coordinates in the blogs from which the new teams start.I mean, those data that were added to the master before the replication, You don't get a line?The replication procedure itself suggests that you reconstruct a copy of the master first. However, if you can avoid this and not break the replica later, yes, they won't be on the line.