connecting to a Heroku Postgres database using Dbeaver client to after enabling ssl and using org.postgresql.ssl.NonValidatingFactory takes about 4-5 minutes to connect to the database.
Is this behavior normal?
Just uncheck "Show non-default databases".
It crashes / freezes because it tries to load a huge amount of databases in that host
No, this is not normal at all. Connecting should be quite instantaneous. A few seconds is already way too long, and minutes is completely off, so something else is going on.
If you try connecting with some other tool (like psql directly), do you have the same problem? I'd check there to make sure your code or some dependency is not doing something odd.
Related
I upgraded my dev server with mysql 8.0.24 but it doesn't work for me. I keep getting a fatal crash every time a query uses GROUP_CONCAT(DISTINCT... and there are no rows because of the WHERE. Anyway, I'd like to rollback to 8.0.23. Was the file format upgraded? Can I safely go back to 8.0.23?
Thank you.
After some reading, it's not easy to downgrade mysql. Mysql itself says it's not possible: https://dev.mysql.com/doc/refman/8.0/en/downgrading.html
I found some possible solution: https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781788395809/1/ch01lvl1sec18/downgrading-from-mysql-8-0
But in the end, I decided to revert the whole dev server to the last backup; that was easier, just a few clicks and back on my feet.
I have a Linux server where I start a few Ruby programs during the day. The server is directly connected to the internet (no firewall) at a hoster and I wonder, if there is a way to start and close the mySQL server just before I update the db and close it afterwards. The target is, to have the mySQL server only open when it is needed. So I thought it might be a way to activate the port or the service directly out of Ruby.
thank you for answering,
Werner
You'd probably have to change the permissions to the database through ruby, then, doing whatever you want to do, and change the permissions back.
You could do that usig the mysql gem, connecting to the database and running the commands.
Then restart the process, and do the same thing but backwards
Honestly, I don't know why you would do that, and I wouldn't recommend someone to do that. But that would be my approach
I've been a MySQL guy, and now I'm working with Postgres so I am learning. Wondering if someone can tell me why my postgres process on my macbook is sending and receiving data over my network. I am just noticing this is happening for the first time - so maybe it's been going on before this and I just never noticed postgres does this.
What has me a bit nervous, is that I pulled down a production datadump from our server which is set up with replication and I imported it to my local postgres db. The settings in my postgresql.conf don't indicate replication is turned on. So it shouldn't be streaming out to anything, right?
If someone has some insight into what may be happening, or why postgres is sending/receiving packets, I'd love to hear the easy answer (and the complex one if there's more to what's happening).
This is a postgres install via Homebrew on MacOSX.
Thanks in advance!
Some final thoughts: It's entirely possible, I guess, that Mac's activity monitor also shows local 'network' traffic stats. Maybe this isn't going out to the internets.....
In short, I would not expect replication to be enabled for a DB that was dumped from a server that had it if the server to which it was restored had no replication configured at all.
More detail:
Normally, to get a local copy of a database in Postgres, one would do a pg_dump of the remote database (this could be done from your laptop, pointing at your server), followed by a createdb on your laptop to create the database stub and then a pg_restore pointed at the dump to populate its contents. [Edit: Re-reading your post, it seems like you may perhaps have done this, but meant that the dump you used had replication enabled.)]
That would be entirely local (assuming no connections into the DB from off-box), so long as you didn't explicitly setup any replication or anything else that would go off-box. Can you elaborate on what exactly you mean by importing with replication?
Also, if you're concerned about remote traffic coming from Postgres, try running this command a few times over the period of a minute or two (when you are seeing the traffic):
netstat | grep postgres
In general, replication in Postgres in configured at a server level, and has to do with things such as the master server shipping WAL files to the standby server (for streaming replication). You would have almost certainly have had to setup entries in postgresql.conf and pg_hba.conf to ensure that the standby server had access (such as a replication entry in the latter conf file). Assuming you didn't do steps such as this, I think it can pretty safely be concluded that there's no replication going on (especially in conjunction with double-checking via netstat).
You might also double-check the Postgres log to see if it's doing anything replication related. In a default install, that'd probably be in /var/log/postgresql (although I'm not 100% sure if Homebrew installs put it somewhere else).
If it's UDP traffic, to and from a high port, it's likely to be PostgreSQL's internal statistics collector.
These are pre-bound to prevent interference and should not be accessible outside of PostgreSQL.
I'm new to use oracle BIEE.My development enviromnent now is installed,and the project is a little big.Multi user development is using for developing now.The problems happens when one developer publish the rpd to network and want to test the data,the server reloading the rpd file takes too much time and I can hardly wait!When multi users want to test rpd file,e,can't stand it... is there any other way to solve the problem?or how to make the biee sever reload the rpd file quickly?
It's hard to say specifically without knowing a bit more about your setup, but here are a few general advice pointers:
When stopping the service OBI will wait for any running queries to complete before stopping the service, so making sure there's nothing running before you try to do this.
Make sure you're only restarting the BI Server component, you don't need to wait for the other services to restart if you're just changing the RPD (if you're on 11g then deploying through EM should mean this happens anyway so you don't need to worry).
If you're using 11g, you could try incremental updates by creating patches.
Check whether the hardware you're running on is adequate, most importantly that you've enough RAM so it's not having to page out to disk when it loads the RPD.
Remove anything unused from the RPD to make it smaller.
My Heroku app is www.inflationtrends.com.
Usually, when I run "pg:info" in Git Bash to see how many connections there are, that number is zero.
Recently, I've seen a spike in traffic -- not much, only a little over 1,000 in the past 48 hours -- and when I ran "pg:info" this morning (around 11 a.m. Eastern time), the result shows that there are 4 or 5 open connections.
My app is run using the Ruby gem Sinatra. In the Sinatra file, I have the following code:
after do
DB.disconnect
end
The "after do" loop disconnects from the PostgreSQL database after a page is loaded.
The variable "DB" has the connection info for my PostgreSQL database (username, password, host, port number, SSL mode requirement):
DB = Sequel.postgres(
db_name,
:user=>user,
:password=>password,
:host=>host,
:port=>port,
:sslmode=>sslmode
)
Is there some reason that there are open connections? Are there ways to close these connections? Are there more efficient ways to handle this situation?
An alternate way to check the number of open connections on Heroku is to type this into your console/terminal and replace "myapp" with your app's name:
heroku pg:info -a myapp
Have you considered that perhaps your site is getting traffic? When people visit your site and use your application connections will be opened.
Try adding some tracking code (such as Google Analytics) to your web pages, then check if the number of recorded visitors matches the number of open connections.
It is also possible that the database has connections opened by various maintenance tasks, such as backing up.
I grabbed the following toolbelt add-on which worked perfectly.
https://github.com/heroku/heroku-pg-extras#usage
heroku pg:killall --app xyz