Have a look at the Release notes. You need to run all upgrades one-by-one. https://www.mongodb.com/docs/manual/release-notes/3.0-upgrade/#upgrade-a-replica-set-to-3.0 https://www.mongodb.com/docs/manual/release-notes/3.2-upgrade/#upgrade-a-replica-set-to-3.2 https://www.mongodb.com/docs/manual/release-notes/3.4-upgrade-replica-set/ ... https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-replica-set/ Each single upgrade should be possible without service interruption.

Years ago, MySQL supported a way to initialize replication the way you're describing. You configure a replica, and basically tell it to suck the current state of data from the source node. I have never used this feature, and it was quickly removed from the product. I can't even find documentation on this feature now. I think it would have to lock the source table to get the initial state of data, so it would have a pretty high risk that someone could cause an outage by accident just by enabling a new replica. I assume that's why the feature vanished. Recently a plugin called MySQL Clone appears to do the same thing, but it only works with InnoDB tables as far as I can tell. See https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-innodb-cluster-clone-deployment.html Creating a replica does not need to cause downtime on the source instance. At my last job, we did this frequently to add or repair replicas. We used https://www.percona.com/software/mysql-database/percona-xtrabackup to create a hot backup from the source node, and transferred that backup to the replica server, then started replication using the binary log coordinates recorded with the backup. Once we converted all our clusters to GTID, that got even easier. But I think your task is even easier than this. You don't need to use replication to convert the storage engine of a table. I would use https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html , a free tool that allows you to use ALTER TABLE on a table with virtually no downtime.

I think you are mixing up things from logical and WAL (physical) replication, which adds to the confusion. Despite being both called "replication", these have quite different mechanisms and require different configuration. Depending on the kind of replication you want to set up, you should refer to the appropriate section of the documentation. wal_level is set on the primary and determines the amount of information written to the WAL. The replica value causes more information to be written than minimal, and logical more information yet. In releases prior to 9.6, this parameter also allowed the values archive and hot_standby. These are still accepted but mapped to replica In contrast, hot_standby parameter (not the wal_level value) only affects the replica because it changes the replica behaviour. The distinction between "hot" and "warm" only applies to physical standby servers, as they are in a continuous recovery state, accepting and applying WAL records from the primary. A database would not normally be accessible in this state, but setting hot_standby = on allows you limited (read only) access. Logical replicas are always "hot" in the sense that the receiving databases are in the fully operational state.

No, if you have restore_command defined properly on the standby server, you don't need wal_keep_segments (wal_keep_size in later versions) on the primary. If you define restore_command on the standby, it will restore the WAL segment from there. You say that the WAL segment gets archived and recycled on the primary, so the standby must be able to get it from there. The standby should try to fetch the WAL segment from archive, even if it already has a partially filled local WAL segment with the same name. I would consider anything else a bug. Are you sure that restore_command is set on the standby? Don't you get any messages about "restoring WAL segment from archive"?

As long as the second server is also the 2019 version, then I don't think you'll have any issues technologically. But you have to be careful not violate your licensing agreement with Microsoft by using the Developer edition server for any production purpose. I'd recommend speaking to Microsoft or your Microsoft var to verify that side of things. To your follow up question on which type of replication you should use, it depends on your use case and requirements: https://docs.microsoft.com/en-us/sql/relational-databases/replication/transactional/transactional-replication?view=sql-server-ver16 is probably the most commonly used kind. It is very configurable and flexible, and it replicates changes in near-realtime. (It replicates only the changes after the initial snapshot is synchronized.) One of the biggest requirements to use it is that any replicated tables need a primary key defined on them. A workaround for this is to create an indexed view which is applicable for replication because of its unique clustered index. https://docs.microsoft.com/en-us/sql/relational-databases/replication/snapshot-replication?view=sql-server-ver16 is probably the next most commonly used kind of replication. It can be scheduled to run at a frequency of your choice but it drops and re-creates the entities being replicated, every time. This makes it a heavier type of replication than Transactional, and usually is not used for realtime synchronization. https://docs.microsoft.com/en-us/sql/relational-databases/replication/merge/merge-replication?view=sql-server-ver16 is another form of replication similar to Transactional, and can be used for realtime synchronization. I don't believe it has the same requirements as Transactional, in the sense that it can replicate tables without primary keys on them. But it has its own requirements. It's also useful for when your Subscriber database needs to be applicable for data changes that need to be propagated back to the Publisher, which is not usually possible with regular Transactional Replication (but I believe Transactional Replication with Updatable Subscriptions does allow this). https://docs.microsoft.com/en-us/sql/relational-databases/replication/transactional/peer-to-peer-transactional-replication?view=sql-server-ver16 is a fourth kind of replication that is also a type of Transactional Replication. (I never had a use case for it, so I don't know much about it, but please see the linked docs.)

1.cat network dns 2.ping ping ip/hostname must ok 3.need check error log

b) confirmed from fivetran support, this is an expected behavior and this value is true only when active replication is happening. waiting for the required WAL log which was already flushed at postgres side. postgresLSN (fivetran side) can be manually updated by fivetran support with the latest available restart_lsn value(data might be missing) or can resync the complete data to resolve the issue.

Depending on which flavour of Azure SQL is being used you may be able to implement https://docs.microsoft.com/en-us/sql/relational-databases/resource-governor/resource-governor or equivalent. This allows you to allocate a portion of the hardware to each workload. The large slow queries cannot flood the buffer pool. Many small queries cannot starve the others of processing quanta. Of course the machine is still finite. Each group gets less than the whole machine but is guaranteed to never get none of it. If all groups need more performance the instance has to be scaled up. If you are at the upper limit of scale-up the only option is scale-out, with replication or sharding as appropriate. Replicating 400TB may prove, umm, interesting; don't know, never tried. I should think at that scale you would command some attention from your local MS sales team. See if they can get you some time with an MS solution architect.

FLUSH TABLES WITH READ LOCK is sufficient. This locks the tables, preventing new writes, and it also makes sure any other writes to tables are flushed to the disk volume for MyISAM tables. For InnoDB tables, some changes may still be in the buffer pool, but those change are also accounted for by the InnoDB redo log, so as you start up the replica those changes will be restored automatically (this is the same as InnoDB crash recovery). Using SHOW MASTER STATUS during the read lock is necessary because you need those coordinates for your CHANGE MASTER command on the replica. It's basically analogous to a bookmark, so the replica knows where to start reading in the binary log. It is still important to listen to the advice about long-running queries blocking FLUSH TABLES WITH READ LOCK. Any query, even a read-only SELECT, holds a metadata lock on a table. But FTWRL requires no metadata locks held on any tables, at least briefly. So a long-running SELECT will block FTWRL. You can do an experiment to demonstrate this on a test instance of MySQL: In one window, create a MyISAM table: mysql> create table test.m (i int) engine=myisam; mysql> insert into test.m values (42); Query it in a way that will last some time: mysql> select sleep(120) from m; (hangs) In a second window, try FTWRL: mysql> flush tables with read lock; (hangs) The FTWRL is waiting for that query to finish, so FTWRL can get its own turn at the metadata lock. If that query takes a long time to finish, FTWRL will still be waiting, and also any other queries will be queued up waiting for FTWRL to release its metadata locks on all tables. Percona added a feature to their version of MySQL to help in these situations. It's a lock used during backups which does not suffer this blocking behavior. Read https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/ for details if you're interested, but if you use mainstream MySQL, you don't have this feature. The LVM snapshot method is a pretty good solution given that you have a mix of InnoDB and MyISAM tables, because the lock can be done pretty briefly, just long enough to acquire the LVM snapshot and read the MASTER STATUS. I'm accustomed to using Percona XtraBackup, which does not require locking, as long as the database stores only InnoDB tables (except for the mysql system tables, which are very small, so they are not a problem to back up during a brief read lock). It's my preference to insist that all tables are stored in the InnoDB. MyISAM has poor performance and is susceptible to data corruption.

I've mostly only worked with Transactional Replication so I'm not an expert on Merge Replication, but maybe it's just a matter of taking and restoring a backup of the Subscriber database? Here's the docs on https://docs.microsoft.com/en-us/sql/relational-databases/replication/administration/strategies-for-backing-up-and-restoring-merge-replication?view=sql-server-ver15#backing-up-and-restoring-a-subscription-database . It doesn't sound very involved, but make sure to adhere to what it says. If after you restore the Subscriber database backup to another database and it doesn't automatically get picked up by the Publisher, you may need to go through the "Add Subscriber" wizard on that specific Publication (on the Publisher's server). I'm both cases I'd recommend also re-initializing the Snapshot for that Publication.

So I figured out the problem. pg_upgrade will not migrate the pg_replication_origin data, hence I had to re-create the origins using pg_replication_origin_create and the replication was replicating again.

I cannot guarantee that these suggestions will solve your problem. These are common issues that I am aware of why data is not deleted from the two tables you mentioned even though the data has been replicated to all subscribers. Please check that none of your publications has immediate_sync = true. Please check that none of your publications has allow_anonymous = true. Once you fix these two settings, you can run the cleanup job manually or reduce the max retention period. In order to change the settings you can use this command as a sample. DECLARE @publication AS sysname SET @publication = N'AdvWorksProductTran' -- Turn off DDL replication for the transactional publication. USE [AdventureWorks2012] EXEC sp_changepublication @publication = @publication, @property = N'allow_anonymous', @value = N'False' GO Reference: https://www.mssqltips.com/sqlservertip/2668/role-of-the-immediate-sync-option-for-sql-server-replication/ by Mohammed Moinudheen https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-changepublication-transact-sql?view=sql-server-ver15#impact-of-immediate-sync https://www.sqlservercentral.com/forums/topic/msrepl_commands-not-cleaning-out

What you needed to set up was "dual-Primary" (aka "dual master"). This is where each of the two servers was both Primary and Replica to the other. That way, you would already have set up the replication mechanisms so that failover and fallback would be the same process.

It depends greatly on the purpose of the two tables. For example, if table A is about shops in a city, and table B is about customers in a city, those two addresses are completely unrelated and it wouldn't make any sense to link them. In a different scenario, if table A is about employees of a company, and table B is about the members of the company's football team, then each football player is also an employee and having duplicated addresses is a) redundant and b) prone to data discrepancies.

I don't believe it is possible to do so in your version of SQL Server other than how you described, or alternatively by removing that specific Table Article from your Publication and then re-adding it when you're done. Microsoft released a https://support.microsoft.com/en-us/topic/kb3170123-supports-drop-table-ddl-for-articles-that-are-included-in-transactional-replication-in-sql-server-2014-or-in-sql-server-2016-sp1-f412e258-fde1-4246-728f-b89623ba3933 that let's you drop a Table that's being replicated if you specify the allow_drop property on all Publications that replicate that Table Article. This is also available in all subsequent versions of SQL Server as well. You should consider upgrading versions soon anyway since https://docs.microsoft.com/en-us/lifecycle/products/microsoft-sql-server-2012 . Then it will no longer be officially supported by Microsoft.

Usually the following ports must be opened for inbound traffic: TCP 1433, 1434, 135, 80, 443; UDP 1434. Replication connections to SQL Server use the typical regular Database Engine ports (TCP port 1433 is the default instance) Web synchronization and FTP/UNC access for replication snapshot require more ports to be opened on the firewall. To transfer initial data and schema from one location to another, replication can use FTP (TCP port 21), or sync over HTTP (TCP port 80) or File Sharing. File sharing uses UDP port 137 and 138, and TCP port 139 if used along with NetBIOS. File Sharing uses TCP port 445. For sync over HTTP, replication uses the IIS endpoint (configurable; port 80 default), but the IIS process connects to the backend SQL Server through the standard ports (1433 for the default instance). usually you can set up subscribers in this way: exec sp_addsubscription @subscriber = 'Server,port'. try with IP and custom port https://docs.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-ver15

One option is to put an AG replica on the target server, to serve as a staging database, and then upsert from there to the DW.

1.use pt-table-checksum tool for master and slave data 2.skip the error mysql> stop slave; mysql> set @@session.gtid_next='xxxxx'; mysql> begin; mysql> commit; mysql> set @@session.gtid_next=automatic; mysql> start slave; mysql> show slave status \G

(I may be one of the few old-timers around who has used MyISAM with replication.) "not use the InnoDB" -- Ouch! Especially for such large tables. Testing on single server -- Fine. But I suggest encapsulating them in some form of VM, such as Docker, so you can closer simulate the ultimate configuration, which will probably have port 3306 on all servers. binlog_do/ignore_... prevents shipping the indicated things out of the Primary. replicate_do/ignore_... tosses the replicated data after it reaches the replica. Do whichever is needed, being aware of the impact on the network. Yeah, the rsync script sounds like a sledgehammer, and slow. Even a one-row change in a table might necessitate megabytes of data to be shipped. Galera or InnoDB Cluster is a much better way to deal with the possibility of a crashed server. They take care of themselves without scripts like you describe. (Both require InnoDB, not MyISAM.) "Sometimes I get errors" -- can't address this without more details. MyISAM will almost always have errors after a power failure. Furthermore, the data can become inconsistent. Both of these issues do not happen with InnoDB. There are many reasons for "slave lagging behind". The table locks of MyISAM is one. Long queries is another. (Galera has two techniques for helping with big ALTERs, depending on the details.) There is even a bogus "slave behind" that might actually be fixed soon, after 20! "loads of 15" -- Do you mean "Load Average"? That sounds rather bad. But it sounds wrong since Max_used_connections=2. Do you have the slowlog turned on? It probably indicates which queries are being naughty. A glance at the STATUS shows a QPS that is very small. And it looks like you have a lot of queries in stored routines? GLOBAL STATUS is only partially useful without a full listing of VARIABLES. I'm pretty sure Docker is better than datacharmer's 11-year-old techniques. Oh, did I mention that you should switch to InnoDB? More info: http://mysql.rjweb.org/doc.php/myisam2innodb

No, that is not possible. For one, the destination table would have to have the same name and lie in the same schema. Trigger-based replication is also not an option, because you cannot have triggers on catalog tables. Foreign tables are your only choice. If the connection is unstable, use a materialized view on top of the foreign table and take snapshots regularly. That way you have at least the most recent snapshot.