I want to replicate postgresql data of windows server to linux server, I know how to replication between same operating systems but that method is not working with windows and linux. If yes what would be the better way to do this?
You cannot use streaming replication between different operating systems.
Look at the PostgreSQL Wiki for a list of replication solutions. Some of them should work for you.
From PostgreSQL v10 on, you could consider logical replication.
Done this using Postgresql 9.5.21 as master on Windows 2012 R2 and slave on Ubuntu 14.04.
You have to take care about a few things:
most similar CPU (page size, architecture, registers). So, you can't mix 64/32bit, or using CPU with different endianess or page size;
same endianess also for the O.S.: both 32 or 64 bit;
same major version of PG: 9.5.x with same or other 9.5.x version (that's for streaming replication, that I'm using, Logical Replication works with different versions of PG);
So, I find an already installed PG on Windows Server. Edit postgresql.conf to enable replica and PITR, and pg_hba.conf to allow connection.
Then moved on Ubuntu and, with PG stopped, I fetched from the master with:
pg_basebackup -D /tmp/db/ -X stream -R -U postgres -h ip-master
Then modified configuration and replaced data directory with /tmp/db.
Start slave, and is up and running, but look at this:
2020-03-18 21:05:31.598 CET [44640] LOG: database system is ready to accept read
only connections
2020-03-18 21:05:31.631 CET [44645] LOG: started streaming WAL from primary at 36/C2000000 on timeline 1
2020-03-18 21:05:31.905 CET [44646] [unknown]#[unknown] LOG: incomplete startup packet
2020-03-18 21:05:32.416 CET [44649] postgres#postgres FATAL: database locale is incompatible with operating system
2020-03-18 21:05:32.416 CET [44649] postgres#postgres DETAIL: The database was initialized with LC_COLLATE "Italian_Italy.1252", which is not recognized by setlocale().
2020-03-18 21:05:32.416 CET [44649] postgres#postgres HINT: Recreate the database with another locale or install the missing locale.
Here's the funny thing: replication works, but you can't connect to the databases.
Anyway, if you raw copy the data dir on Windows, it works like a charm.
Of course, if you re-create the cluster with UTF-8, there's no problem at all.
n.b.: thanks a lot to incognito and ilmari on official IRC PG channel for the hints.
Related
I have observed quite some time that the connection attempt to an Oracle server using OCI library hangs forever and I am not able to find a way out to cancel the hung session. Even Ctrl+C doesn't work.
Do we have an option to call OCIServerAttach API in non-blocking mode or is there is an option that can be used to timeout the OCIServerAttach call?
Please note that the OCI version I am using is 11.2.0
Oracle Net can be configured to limit the connection establishment time. The available options have been enhanced in various versions. Oracle 11.2 is 10 years old!!
For recent versions (check the manual for your version), you could create a sqlnet.ora file with options like SQLNET.OUTBOUND_CONNECT_TIMEOUT or TCP.CONNECT_TIMEOUT, or use CONNECT_TIMEOUT in a tnsnames.ora file. Search for 'connect_timeout' in that manual for other choices.
If you use 19c client libraries (that, by the way, will connect to Oracle DB 11.2 or later) then you can even use a timeout option in an Easy Connect connection string like "mydbmachine.example.com/orclpdb1?connect_timeout=15"
I am running mariadb 5.5.2 on two Centos 7.1.1503 bare metal Dell servers. The servers are each 16 months old. They were never rebooted until July 2017. Call the first server salt01 call the second one salt02. salt02 was rebooted first, salt01 was rebooted next.
Since then, have noticed that the db on salt02 is missing entries we see on salt01. Those records co-incide with the reboot; that is, data is missing since then but previous data is present on salt02.
iptables is not running on these two servers.
This appears to be replication issue.
We have two ways to fix:
Follow a re-sync procedure that goes like this:
At the master:
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
mysqldump -u root -p --all-databases > /a/path/mysqldump.sql
UNLOCK TABLES;
and on slave:
STOP SLAVE;
mysql -uroot -p < mysqldump.sql
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=valuefromshowmasterstatus;
START SLAVE;
Fix replication
Notice this in file /etc/my.cnf
bind-address = 127.0.0.1
on salt02 which is believed to be slave. How critical is this? Could point bind-address to master salt01 and restart mariadb on salt02
Was wondering about thoughts on which way to go here. I'm not a dba. Many thanks for your thoughts? Any questions feel free.
I need to automatize sqlserver scripts from a linux environment.
I saw Microsoft released a linux version of its ODBC driver, that also includes sqlcmd for linux. Though, it's only available for redhat.
I found a few tutorials to force installation on several other linux versions (including debian), but they seem to be out of date : many points are wrong or -- probably -- not suited anymore.
I also tried to install and run sqsh, but I got an error trying to connect, and miss the guides to help configure it
sqsh -S xy.zk.lm.opqr -U sas -D myDB
sqsh-2.1.7 Copyright (C) 1995-2001 Scott C. Gray
Portions Copyright (C) 2004-2010 Michael Peppler
This is free software with ABSOLUTELY NO WARRANTY
For more information type '\warranty'
Password: ...
Msg 18456, Level 14, State 1
Server 'AUB-DB-QUALIF\SQLEXPRESS', Line 1
â–’chec de l'ouverture de session de l'utilisateurâ–’'sas'.
Open Client Message
Layer 0, Origin 0, Severity 78, Number 34
Adaptive Server connection failed
Since I miss skills using linux, I may not see the "obvisous" way to do it. Thus, if you have any - up-to-date - tip or trick to help run sqlserver as a command line under linux, I'll read you with great attention!
Thanks in advance.
Today 2016-11-17 Microsoft released a public preview of SQLServer for Linux (supporting Linux, Mac, Docker,... ) may be you chan use the any of the new versions with the benefits of SQLCMD.
SQL Server for Linux
I am unable to login to 'postgres' database as 'postgres' user.
OS : REHL Server release 6.3
Postgresql version: 8.4
There is a Database 'jiradb' which is used as a Backend for JIRA 6.0.8.
When I give the command
[root ~]#psql postgres postgres
Password for user postgres: *******
psql: FATAL: could not open relation with OID 2696
How do I fix this error and login to 'postgres' database. Please ask me if you need more details. I am new to postgres DB.
Thanks.
Your postgres database is damaged. oid 2696 is a system reserved oid, so it's a system table, and their oids are stable across databases and across versions. Looking it up on my 9.4, it's:
regress=> select relname from pg_class where oid = 2696;
relname
----------------------------------
pg_statistic_relid_att_inh_index
(1 row)
regress=> \d pg_statistic_relid_att_inh_index
Index "pg_catalog.pg_statistic_relid_att_inh_index"
Column | Type | Definition
------------+----------+------------
starelid | oid | starelid
staattnum | smallint | staattnum
stainherit | boolean | stainherit
unique, btree, for table "pg_catalog.pg_statistic"
so you have a missing file in the data directory for the index pg_statistic_relid_att_inh_index on the system table pg_catalog.pg_statistic.
This should not happen. You have at lest limited data corruption in your datadir.
Your first action should be to stop the database and make a full filesystem-level copy of the entire data directory, per PostgreSQL wiki - corruption.
Then check for possible causes. Recent disk issues? Unexpected/sudden shutdowns followed by fsck, possibly on a system with a non-crashsafe file system, unsafe mount options (e.g. ext3/ext4 data=writeback), unsafe configurations like ext[34]-on-LVM-on-md with barriers on older kernels, etc. Also make sure you're on the latest 8.4 point release.
Only once you have made a full file system level copy of the data directory to safe read-only storage, start the database back up (but not the applications that use it) and see if you can connect to jiradb e.g. psql jiradb. If you can, promptly perform a pg_dump of jiradb and any other databases with data of value.
Do not keep on using the damaged data directory. Now is a good time to do a dump and reload - do a pg_dumpall --globals-only, a pg_dump -Fc of each database, then move the datadir aside, re-initdb, and start back up with a clean install. You might even want to upgrade to a less ancient PostgreSQL at the same time.
Note that it is generally possible to fix issues like this in-place. In this case, if your damaged database wasn't the unimportant-and-usually-empty postgres database, you could start PostgreSQL up in single-user mode with system indexes disabled, then REINDEX the damaged index.
I just can't connect to Firebird on Ubuntu.
Through the terminal I do:
rafaeljesus#ubuntu:/tmp$ isql-fb
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect .my_database.gdb user sysdba password masterkey;
Statement failed, SQLSTATE = -922
file /tmp/cnes.gdb is not a valid database
Searching on the web I realized that this occurs when the file is corrupted, which is not the case ... I do not know if this is because the file is in gdb. instead of fdb..I do not know about Firebird ...
I really need some help.
As you don't specify any version information, ODS version of the database, if you upgraded the Firebird version, or whether this database was moved from another system etc I provide some options:
The database was created on a 32 bit platform and now moved to a 64 bit platform without backup/restore: older file structures of Firebird (at least ODS 10 from Firebird 1.0 and InterBase 6) are specific to the bitness of the platform: a backup on the 32 bit platform and a restore on the 64 bit platform should suffice
The database was created on a big-endian platform and now moved to a little-endian platform without backup/restore
NOTE: In both cases make sure you create a transportable backup (it is the default, but check).
Another option could be that a restore of the database failed before the full database was restored. Check your restore log and address any errors (see Firebird 2.5 reports "is not a valid database" although it is for a suggestion )
If all else fail: contact a Firebird/Interbase recovery/repair company like IB Surgeon.