Comprehensive data protection for all workloads
Post Reply
mcz
Veeam Legend
Posts: 851
Liked: 180 times
Joined: Jul 19, 2016 8:39 am
Full Name: Michael
Location: Rheintal, Austria
Contact:

Migration to Postgresql fails

Post by mcz »

Hi everyone,

v12 is now available since 9 months, so I thought it was worth to switch to pgsql as my current mssql-instance is not performing well at all...
Googled a bit and found the following guide:

https://www.veeam.com/blog/switch-sql-s ... veeam.html

So far so good, give it a try. Everything went well until it tried to create some indexes on the pg-database - there it failed with a duplicated index message. Weird!

Now I'm convinced that this step has been tested and tried thousands of times, so I wonder what the root cause here might be. I've installed the 64-bit-version of pg 15.5 (build 1914), is that probably not supported yet? The release notes say the following:
PostgreSQL 14.x, 15, and 15.1 (version 15.1 is included in the setup, but we strongly recommend downloading and installing the latest PostgreSQL 15.x version)
So if I read it correctly, 15.5 should be supported according to the last sentence? Or should it be 15.1.x?

Thanks for the clarification!

PS: Haven't created a ticket so far, will do if I don't get a quick answer here.
haslund
Veeam Software
Posts: 839
Liked: 149 times
Joined: Feb 16, 2012 7:35 am
Full Name: Rasmus Haslund
Location: Denmark
Contact:

Re: Migration to Postgresql fails

Post by haslund »

I would strongly recommend to open a support ticket and include your log files. Our support team can help pinpoint the exact issue. Feel free to let us know the ticket ID once it has been created.
Rasmus Haslund | Twitter: @haslund | Blog: https://rasmushaslund.com
mcz
Veeam Legend
Posts: 851
Liked: 180 times
Joined: Jul 19, 2016 8:39 am
Full Name: Michael
Location: Rheintal, Austria
Contact:

Re: Migration to Postgresql fails

Post by mcz »

Yeah but how should I read the release-notes? Is 15.5 supported or not?
Mildur
Product Manager
Posts: 8735
Liked: 2296 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Migration to Postgresql fails

Post by Mildur »

Hi Michael

The release notes may not always be up to date. But our user guide is. 15.x is supported.
v12.1 will provide updated release notes.
https://helpcenter.veeam.com/docs/backu ... kup-server
- PostgreSQL 14.x
- PostgreSQL 15.x (PostgreSQL 15.1 is included in the Veeam Backup & Replication setup, but we strongly recommend to download and install the latest PostgreSQL 15.x version)
Best,
Fabian
Product Management Analyst @ Veeam Software
AlphaOmega
Novice
Posts: 3
Liked: 1 time
Joined: Nov 27, 2023 9:46 am
Contact:

Re: Migration to Postgresql fails

Post by AlphaOmega »

mcz wrote: Nov 27, 2023 7:59 am Yeah but how should I read the release-notes? Is 15.5 supported or not?
Of course. Every version of major Version 15 is.

FYI: We did the migration with 15.4 and upgraded to 15.5 last week. No Problems encountered.
Gostev
Chief Product Officer
Posts: 31561
Liked: 6725 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Migration to Postgresql fails

Post by Gostev »

Veeam 12.1 will ship with PostgreSQL 15.5 as well.
mcz
Veeam Legend
Posts: 851
Liked: 180 times
Joined: Jul 19, 2016 8:39 am
Full Name: Michael
Location: Rheintal, Austria
Contact:

Re: Migration to Postgresql fails

Post by mcz »

Thanks Anton & AlphaOmega. Just created case #07026596. Even with a 15.1 installation, it doesn't work and I'm sure (after also reading this post here), it is not due to the version of the db.
Let's see what support finds out. Basically it says that it tried to create the index "ix_sessionid_cookie_deleted" but failed due to a duplicate.

Looks odd to me...
mcz
Veeam Legend
Posts: 851
Liked: 180 times
Joined: Jul 19, 2016 8:39 am
Full Name: Michael
Location: Rheintal, Austria
Contact:

Re: Migration to Postgresql fails

Post by mcz »

ok, the issue is fixed - some values in the Cookie-table has lead to that issue... In general, it's not the first time this year that support had to edit the database due to some really weird records, which surprises me. I mean I never edited the DB manually by myself and so the only assumption I can make is that some processes are not ideal designed in terms of transaction logic...

Is this a very rare case or will there be improvements in the future? Thanks!
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Semrush [Bot] and 95 guests