I have an important issue with my database and I don't know how to fix it.
I have postgresql 9.6 in CentOS running. After a system reboot, postgrsql-service doesn't start, so following the instructions in the shell, I launched "sudo /usr/pgsql-9.6/bin/postgresql96-setup initdb"
What my surpirse when I started pgsql... and it is a new empty instance, I had a database with a size of 4GB and has dissapear...
However data must be still in the files, because data folder have a size of 4GB, how I can recover this last situation?
Thank you very much,
Regards,
Related
User postgres is running a process that take all CPUs at 100% usage in a centos machine, the postgresql service is not running so it cannot be a query.
When I try to stop the process it restarts itself. Then name of the process is somewhat strange.
Congratulations!
By exposing a database with a weak superuser password to the internet you invited somebody to break in and use your CPU for their own purposes, probably mining crypto-currencies.
Take the machine from the internet, wipe it clean and re-install the operating system.
I had the same issue on my VPS. I considered to reinstall OS or clone VPS, but have alot of issues on that solution. So, i choose another way:
I did:
backup all data with "pg_dumpall"
backup pqsql configuration(pg_hba.conf,postgresql.conf,...)
Uninstall "everything" of pgsql
reinstall pgsql
restore pgsql data
Done
My hoster upgraded my Ubuntu server and it's not booting any more. The only way I can access my data any more is in read mode via a rescue environment (SSH shell).
I am running a postgres 9.1 installation on the crashed server. I am not able to start the postgres server in the rescue environment. I also do not have a dababase dump created with pg_dump.
However, I was able to copy the whole /var/lib/postgresql folder to a new machine . I installed Postgres 9.1 on this machine. Afertwards I replaced the /var/lib/postgresql with my old files.
When I start the postgres server, I get something like "incorrect checksum in control file".
I there any way to restore the database content without using pg_dump (since I don't have a current dump and I am not able to run it on the defective machine).
Indeed it was an issue between 32bit and 64bit. I had another old server running on 32bit Ubuntu. Initially I tried to restore the data on a 64bit machine. With the 32bit machine it simply worked by copying the postgres main directory. Finally I was able to log into the database and create a dump.
User postgres is running a process that take all CPUs at 100% usage in a centos machine, the postgresql service is not running so it cannot be a query.
When I try to stop the process it restarts itself. Then name of the process is somewhat strange.
Congratulations!
By exposing a database with a weak superuser password to the internet you invited somebody to break in and use your CPU for their own purposes, probably mining crypto-currencies.
Take the machine from the internet, wipe it clean and re-install the operating system.
I had the same issue on my VPS. I considered to reinstall OS or clone VPS, but have alot of issues on that solution. So, i choose another way:
I did:
backup all data with "pg_dumpall"
backup pqsql configuration(pg_hba.conf,postgresql.conf,...)
Uninstall "everything" of pgsql
reinstall pgsql
restore pgsql data
Done
I was trying to follow the instructions from postgresqltutorial to load a sample database into postgresql using pgadmin. But after the database was restored(since I can query data from the database), the process watcher just won't go away, and it keeps saying that the command is "running"(as of this writing, it has been running for over 400 thousands seconds, but the size of the sample database is just a few megabytes). Reboot and reinstallation couldn't fix the problem.
Here are some screen shots:
And when I click "click here for details":
I am using postgresql 9.6 with pgadmin4 on windows 10. So what's going on here? Is it a bug? How can I get rid of the process watcher?
I had the same issue with posgresql 9.5 and pgAdmin4 on Windows 7. I solved it without loosing server list by opening %APPDATA%\pgAdmin\pgadmin4.db file with SQLite Manager (Firefox Add-on) and deleting all entries from the 'process' table.
This is a bug in pgAdmin4 & reported,
https://redmine.postgresql.org/issues/1679
close pgAdmin, restart the system, open %APPDATA% and erase the folder pgAdmin and the pgAdmin is Ready to start without errors.
Greetings
I have been adding files to GridFS in my 32bit Mongo database. It eventually failed when the size of all Mongo files hit 2Gb. So, I then deleted the files in GridFS. I've tried running the repairDatabase() command, but it fails, saying "mongo requires 64bit for larger datasets". I get the same error trying to run the compact command against GridFS.
So, I've hit the 2Gb limit, but it won't let me compact or repair because it doesn't have space. Talk about Catch22!!
What do I do?
Edit
This is an immediate problem I have - how do I compact the database right now?
I think the only recourse is to upgrade to a 64-bit OS.
I had the same problem on my database and I solved it such way. At first I created Amazon EC2 64-bit instance and moved database files from 32-bit instance via plain copy. Then I made all needed cleanups in database on 64-bit instance and made dump with mongodump. This dump I moved back to 32-bit instance and restored database from it.
If you need to restore database with same name, that you had before, you can just rename your old db-files in dbpath (files have database name in their name)
And of course, you should move to upgrade to 64-bit later. MongoDB on 32-bit OS is very bad in support.
shot in the dark here... you could try opening a slave off the master (in 64 bit) and see if you can force a replication over to the slave, essentially backing up your data. I have no idea if this would actually work, as it's pretty clear that 32bit has a 2gig limit (all their docs warn about this :( ), but thought I'd at least post a somewhat potentially creative solution..