I have a server with postgresql 13 and several postgresql clients that are mutually synchronized by logical replication. Due to problems with the replication in base A that I couldn't solve, I decided to create another identical base B, pass all the data from A to B and start the replication with base B. Then I deleted all the bases A with their subscriptions and publications. The procedure worked quite well but now there are processes trying to connect to base A and I can't find what they are, I already checked all the databases of all the machines with their publications, subscriptions and slots and I can't find any publications or subscriptions that reference to base A!
The log on the server only says:
2022-11-10 09:28:12.344 -03 [6628] FATAL: database "A" does not exist
Is there a way to search the catalog by database name to try and find who is connecting?
Related
I want a solution that match the below scenario:
We have 2 databases with 1 being the main DB and the other being the secondary DB. I want a process (executable, powershell, anything...) that can update the changes that I make in Stored Procedures in the main DB. the main DB is the database that we will make the changes then I want a process that update (simple delete and create) the older SP in the secondary DB.
How I can make this possible in the most simply way? If you will say software to work with please take in account that I only want freeware.
It seemed like you are defining something called Mirroring if I didn't assume wrong.
Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. Typically, these server instances reside on computers in different locations. Starting database mirroring on a database, initiates a relationship, known as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server), depending on the configuration and state of the mirroring session. When a database mirroring session is synchronized, database mirroring provides a hot standby server that supports rapid failover without a loss of data from committed transactions. When the session is not synchronized, the mirror server is typically available as a warm standby server (with possible data loss).
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017
Hope it helps
I need to syncronize two openerp physically distanced databases. One database is on local install, and the second database must on a cloud environment.
Since I lack of good internet access, I cannot have the system working full time on cloud, and the solution is to allow access to the database via cloud (A) and local install (B). When I am on the company, I use the local install (A), and when outside the company, I use the cloud Odoo system (B).
With synchronization, I want to have all data entered on the cloud A available on the local install B and vice-versa.
The synchronization should be time defined and/or on demand.
Any help?
you have to search about something called : Replication.
there are of types of replication, and what you are searching about is : Multi master replication.
it's a little bit complex processus to set up a replication between database and monitor that replication, so i will give you some useful ressources.
Replication Clustering and long pooling in PostgreSQL.
Replication in postgreSQL 9.5 [officiel documentation]
Can anyone explain the differences from a replication db vs a mirroring db server?
I have huge reports to run. I want to use a secondary database server to run my report so I can off load resources from the primary server.
Should I setup a replication server or a mirrored server and why?
For your requirements the replication is the way to go. (asumming you're talking about transactional replication) As stated before mirroring will "mirror" the whole database but you won't be able to query unless you create snapshots from it.
The good point of the replication is that you can select which objects will you use and you can also filter it, and since the DB will be open you can delete info if it's not required( just be careful as this can lead to problems maintaining the replication itself), or create specific indexes for the report which are not needed in "production". I used to maintain this kind of solutions for a long time with no issues.
(Assuming you are referring to Transactional Replication)
The biggest differences are: 1) Replication operates on an object-by-object basis whereas mirroring operates on an entire database. 2) You can't query a mirrored database directly - you have to create snapshots based on the mirrored copy.
In my opinion, mirroring is easier to maintain, but the constant creation of snapshots may prove to be a hassle.
As mentioned here
Database mirroring and database replication are two high data
availability techniques for database servers. In replication, data and
database objects are copied and distributed from one database to
another. It reduces the load from the original database server, and
all the servers on which the database was copied are as active as the
master server. On the other hand, database mirroring creates copies of
a database in two different server instances (principal and mirror).
These mirror copies work as standby copies and are not always active
like in the case of data replication.
This question can also be helpful or have a look at MS Documentation
I tried finding this on the internet but could not find anything regarding it. There are ways to skip errors in the Distribution agent but nothing with respect to skipping Errors while applying Snapshot.
My Question: I have a Multi Publisher Single Subscriber setup. While setting up replication, the Snapshot of the first Publisher is successfully delivered to the subscriber. The snapshot of the consecutive Publishers is successfully generated but fails while applying it to the subscriber. The failure is due to Primary Key violation. Is there a way to skip errors while the snapshot is being applied on the subscriber?
Environment:
Publisher: Microsoft SQL Server 2008 R2 (SP2) - (X64)
Distributor: Microsoft SQL Server 2014 (SP2) (KB3171021) - (X64)
Subscriber: Microsoft SQL Server 2008 R2 (SP3-OD) (KB3144114) - (X64)
I have tried identifying the tables and records which are causing this issue but there are over 100 such tables having hundreds of records each.
Since replication is a client requirement, I don't have much control over the schema and the data in it.
It sounds like something in your setup is incorrect, which is leading to multiple tables from different publishers trying to insert rows into the same subscriber table, hence the duplicate key records.
If the different publishers all have the same copy of the same table, you only want to publish it from one of them.
If the different publishers all have different copies of the same table, you want them to each have their own subscriber tables.
Otherwise you'll end up missing a lot of rows in your subscriber (because different publishers are using the same key for rows that are actually different) or hitting weird replication errors. Just skipping the errors would result in having incorrect data-- and I'm guessing that's one of the client requirements as well.
One option that I have used in the past to simplify replication topography and management:
One subscriber database per publication
Never grant write access to users to these databases
Grant read access via another database which uses synonyms or views
This can make management simpler down the road as well. If you need to re-initialize a single database, you have the option to restore it from backup and generally more flexibility than if your subscribers are all sharing the same database.
Just for completeness, I should probably point you to the Books Online entry from Skipping Errors in Transactional Replication. But to be clear, I think this would be a mistake, as you'd end up with incorrect data -- and that's probably not what anyone wants.
we have a Database Replication set up where we Replicate all Tables of a Database to multiple Production Servers.
There are also Views, Stored Procedures, Functions, etc. in the Database which are manually deployed to the Replicates through TSQL Scripts.
Now if for example a new table is added to the Publication, we have to reinitialize all Subscriptions by creating a new snapshot and let it deliver through the Distributor (which is on the same server as the Publication). The Headache starts when the Distribution Agent wants to drop the Table to recreate it afterwards, some Tables are been referenced by views, which have also been referenced by another objects. the Distributor cannot (or will not) drop the objects and runs into an error like Cannot DROP TABLE 'dbo.table' because it is being referenced by object 'thisisafunctionorview'.
In the past we also had the Views, Functions and StoredProcedures in the Publication but that caused even more Pain (Reinitialisation had to be done after each minor change on procedures, etc.), also then the reference problems where really frustrating.
To resolve this issue we have to drop all functions and views (in total about 200 Objects) and recreate them after the snapshot had been delivered.
Does someone have an idea how we could modify the concept of this replication that we could change objects and not having to set a massive downtime (about 2h for 6 Replicates) to fix the mess because of the references?
To complete the Information:
We use MS SQL Server 2008 R2 on all the instances (with Enterprise and Standard Editions). Upgrade to SQL Server 2014 is planned later this year for the Publisher and some of the Subscribers.
Only the Publication demands writing access.
Updates to the schema of the Database are deployed frequently (about twice a month) usually there are only changes in Procedures but sometimes there were tables added / modified, thats where our replication concept seems to falls apart.
Any suggestions are welcome
Thanks in advance!
Sincerely
David
It sounds strange to me because I have a lot of stored procedures in replication and there is no problems with SP changes. ALTER PROCEDURE can be propagated on subscriptions. Also I see no problems with subscriptions re-initialization because of objects dependencies. I can remember such problems in merge replication though, and there is SP to re-arrange objects. In most cases SQL Server handles dependencies well. Second note, you can add\remove articles to transactional replication without re-initialization.
I think if you re-create replication on test environment and play with it a little bit, you'll find a way how to replicate schema changes and don't do re-initialization too often. It is possible but requires some efforts.