I'm trying to run a Drupal migration via SSH and drush (a command line shell), copying data from a postgres database to mysql.
It works fine for a while (~5 mins or so), but then I get the error:
SQLSTATE[HY000]: General error: 7 SSL [error] SYSCALL error: EOF detected
The postgres database connection seems to have gone, and I just get errors:
SQLSTATE[HY000]: General error: 7 no [error] connection to the server
It works fine locally, so I think the problem must be with postgres and running a script over SSH - but googling these errors returns nothing useful. Does anyone know what could be causing this?
Could be a timeout. first inspect the log (maybe change ssl_renegotiation_limit)
BTW: IIRC, the renegotiation does not take place after a fixed amount of time, but after a certain amount of transmitted characters (2GB?)
You should check both your PostgreSQL and MySQL logs for further potential details. If there's not much in the PostgreSQL log, look at the log_min_error_statement in postgresql.conf. As you'll find through that link, you can tune it to increase the amount of logging. If there's still not clues in the PostgreSQL log, I would look at other components in your system for the problem.
Related
I have a Postgres installed in a Centos and another application is using Postgres the save data.
For sometime, and I can't find the reason, all the database tables become empty on the weekends.
I have been searching a lot to try to find some clues of the reason of that behaviour, but logs are not giving me that info.
I am pretty sure the application is not executing anything to clean the records, my thoughts are pointing to some process for some reason in the Postgres side.
The pg_log only shows this warning the day it happens:
HINT: Consider increasing the configuration parameter "checkpoint_segments".
LOG: checkpoints are occurring too frequently (11 seconds apart)
Apart from that I have no other clues.
Performing a VACUUM ANALYZE VERBOSE it says there is no dead data so it has nothing to delete.
Can you tell me what should I look to get the reason? Should it be any Postgres process to do it?
LOG: checkpoints are occurring too frequently (11 seconds apart)
This log message should also include all the information log_line_prefix tells it to include. So you should set log_line_prefix to include more information, like application name (voluntarily supplied by the client), database username, and host name/IP from which the connection came.
But perhaps more directly at issue, if things are connecting to your database and doing things you don't understand or approve of, it is time to change your passwords.
I am new to freenode and postgresql. I am trying to migrate from mysql to postgresql. Currently trying to set up server for ssl. Have created my server certs and configured the .conf files for ssl according to the manual as far as I can see. Trying to restart postgre sql service fails. Windows event log gives me an event ID of 0 and says
pg_ctrl could not start server examine the log output.
I can't find any log detailing the failure to start in the postgresql folders.
I have tried to register the pgevent.dll as advised by the postgresql manual (18.11 of most recent version), but I get an error message
The module "C:postgreSQL\pg10\lib\postgresql\pgevent.dll" was loaded but the entry-point DllRegisterServer was not found
I believe that means it is either not a registrable dll or it's corrupt.
Can anyone please advise how I can track on Windows the error that is causing Postgre to fail to start?
After running CCleaner and trying to debug a fix an Oauth password encryption type error, I have this error:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications link failure
and all the local databases seemed to have disappeared
I tried to create a new database with MYSQL command line. After entering my password, there was a error and the window closed.
I have tried many solutions to debug the errors e.g. setting
compile('org.hibernate:hibernate-core')
compile('org.hibernate:hibernate-entitymanager')
to resolve an EntityFactory error which lead to this error I think.
I also tried killing the process on port 3306. But I couldn't think of any other options. Any suggestions for next steps would be...?
Apparently mysql service stopped working at some point without me realizing. The solution was going to Start -> type 'service.msc' -> run mysql80 (stands for mysql version 8.0 I think).
I'm trying to download a database to my local machine using pg_dump. The command I'm using is:
pg_dump --host xx.xx.xx.xx --port xxxx --username "xxx" --password --format custom --blobs --verbose --file "testing.db" "xxx"
When it gets to dumping the last table in the database it always crashes with this error:
pg_dump: Dumping the contents of table "versions" failed: PQgetCopyData() failed.
pg_dump: Error message from server: SSL error: sslv3 alert handshake failure
pg_dump: The command was: COPY public.xxx (columns) TO stdout;
I SSH'd into a server that's a bit closer to the server I'm downloading from (I'm in Brisbane, it's in San Francisco) and was able to do the pg_dump without issue. So I know the database server is fine. I suspect it's a timeout because it's getting to the last table before failing; if it was actually an SSL error I'd have expected it to come up sooner. That said, the timeout occurs after a different amount of time each time it fails (the two most recent tests failed after 1300s and 1812s respectively).
Any tips on how to debug are welcome.
I'm on OS X 10.8.5. Local pg_dump is 9.2.4, server is Ubuntu Server running psql 9.1.9.
It might be a SSL renegociation problem.
See this parameter on the server (postgresql.conf) and the associated warning about old SSL client libraries, although OS X 10.8 seems newer than this.
From the 9.1 documentation:
ssl_renegotiation_limit (integer)
Specifies how much data can flow over an SSL-encrypted connection before
renegotiation of the session keys will take place.
Renegotiation decreases an attacker's chances of doing cryptanalysis
when large amounts of traffic can be examined, but it also carries a
large performance penalty. The sum of sent and received traffic is
used to check the limit. If this parameter is set to 0, renegotiation
is disabled. The default is 512MB.
Note: SSL libraries from before November 2009 are insecure when using SSL
renegotiation, due to a vulnerability in the SSL protocol.
As a stop-gap fix for this vulnerability, some vendors
shipped SSL libraries incapable of doing renegotiation. If any such
libraries are in use on the client or server, SSL renegotiation should
be disabled.
EDIT:
Updating this parameter in postgresql.conf does not require a server restart, but a server reload with /etc/init.d/postgresql reload or service postgresql reload.
The value can be also be checked in SQL with show ssl_renegotiation_limit;
Even if the size of the dump is smaller than 512Mb, it may be that the amount of data transmitted is way larger, since pg_dump compresses the data locally when using the custom format (--format custom).
I have two EC2 instances, one of them needs to insert large amounts of data into a Postgresql db that lives on the other one. Incidentally it's Open Street Map data and I am using the osm2pgsql utility to insert the data, not sure if that's relevant, I don't think so.
For smaller inserts everything is fine but for very large inserts something times out after around 15 minutes and the operation fails with:
COPY_END for planet_osm_point failed: SSL SYSCALL error: Connection timed out
Is this timeout enforced by Postgresql, Ubuntu or AWS? Not too sure where to start troubleshooting.
Thanks
Could be caused by renegotiation. Check the log, and maybe tweak
ssl_renegotiation_limit = 512MB (the default)
setting it to zero will disable negotiation