From 182392a5ff61a89014eec550735af8c21ff05b4c Mon Sep 17 00:00:00 2001 From: gennyble Date: Sat, 13 Apr 2024 05:20:01 -0500 Subject: Update date format --- served/words/akkoma-postgres-migration.html | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) (limited to 'served/words') diff --git a/served/words/akkoma-postgres-migration.html b/served/words/akkoma-postgres-migration.html index e7c804b..ea2f671 100644 --- a/served/words/akkoma-postgres-migration.html +++ b/served/words/akkoma-postgres-migration.html @@ -3,8 +3,8 @@ template=post title=Akkoma Postgres Migration style=/styles/post.css style=writing.css -#Summary A retelling of how I migrated my Akkoma instance's Postgres database and the troubles I faced. -#Publish 2023-10-18 + +published=2023-10-18 23:16 --- \(i'm going to say Pleroma a lot here where Akkoma might @@ -21,7 +21,7 @@ style=writing.css

-
+
Recently I went about trying to get the services running on my VPS to be happy in a gig of RAM. I did not achieve this, @@ -47,7 +47,8 @@ to give me the right config lines for 100M. It worked well! This was all for naught, though, because I couldn't get my disk to fit under 25G, which was also a requirement of nanodeisation that I'd forgotten about. The database itself was 9.9G! You can -Prune old remote posts +Prune + old remote posts but I didn't really want to do that yet. It seems like the right way to go, but I had one more trick. @@ -60,7 +61,7 @@ certainly put this on the same server as all my things, but I like having the separation. This does mean that I pay for almost an entire Nanode to do -very nearly nothing. +very nearly nothing. By putting Postgres on it I'd lose the different-machine aspect of the separation, but gain so much disk space and memory. The @@ -69,7 +70,8 @@ good enough for me!

Postgres Migration

-(more of a recount of events than a guide, but written guidlike? just pay mind to the commands and you'll be fine) +(more of a recount of events than a guide, but written guidlike? just pay mind to the commands and you'll be + fine) Install Postgres on the new server. It doesn't have to be the same major version since we're going to dump and restore the @@ -84,7 +86,8 @@ these have to match the database you're migrating from. I followed the Akkoma database restore/move docs and ended up using psql, again under the postgres user, to run CREATE USER akkoma WITH ENCRYPTED PASSWORD '<database-password>'; and -CREATE DATABASE akkoma OWNER akkoma;. (well, i replaced akkoma with pleroma and later used alter queries to change them, but that's because my database is old) +CREATE DATABASE akkoma OWNER akkoma;. (well, i replaced akkoma with pleroma and later used alter queries + to change them, but that's because my database is old) After that was ready, I used my firewall of choice (ufw) to allow the servers to talk using their private IPs (yay same datacenter). After that was done, I ran @@ -92,7 +95,7 @@ this command pg_dump -U akkoma -C akkoma | ssh dynamo "sudo psql -U akkoma and waited. dynamo being the host of the new postgres server and owner of a spot in my .ssh/config. -A Note:
+A Note:
you can directly do pg_dump ... | psql ... but the Postgres upgrade docs say you need to use the new psql version to upgrade, and the old server was missing that binary. Instead of seeing if psql 13 would work or if I could get psql 15 working there, I @@ -138,10 +141,13 @@ does someone like me do when out of luck? Past the error into Google of course! Maybe I should've done that from the start, right, but I don't get many results for Akkoma or Pleroma normally. -So to google I went! And pasted timed out because it queued and checked out the connection for longer than 15000ms +So to google I went! And pasted timed out because it queued and checked out the connection for longer than + 15000ms and then I read -a comment from al2o3cr that said: +a + comment from al2o3cr that said:

Usually that's an indication of database issues, from missing indexes to queries that need optimization.

-- cgit 1.4.1-3-g733a5