Migration of postgresdb for a gerrit 2.14.1 instance

86 views
Skip to first unread message

Mike Lupo

unread,
Dec 5, 2018, 1:11:13 PM12/5/18
to Repo and Gerrit Discussion
Hello all,
Today, I attempted what I thought would be a simple migration of my Gerrit data to a new postgresql server.
It's important to note that the gerrit hosting server isn't changing. Only the db that my config points to is changed.

I followed postgres' directions for pg_dumpall from one db, to the ingestion of that data dump to a shiny brand new db server.
That part seemed to go well.

Following the data migration, I stopped my gerrit instance, changed my etc/gerrit.config file to point to the new db instance, and then restarted the gerrit server. the Gerrit service started up with no issues. 
In my browser I navigated to the gerrit instance. I see all the reviews from myself and other people.

Here's the problem I encountered:
Every one of the users's reviews (except for my own) were attributed to "Anonymous Coward (nnnnnnn)", where n... is their sequential user number.

Did I forget to migrate something?

I could not find a specific documented way to migrate my data to a new server.
Please advise...

Thanks in advance. 




Mike Lupo

unread,
Dec 5, 2018, 1:27:51 PM12/5/18
to Repo and Gerrit Discussion
Adding to this, I did have a user that tried to hit gerrit.
Now, there is some data corruption for THAT user alone.

This is what I see in my logs:

[2018-12-05 18:20:55,957] [HTTP-139] WARN  com.google.gerrit.server.query.account.InternalAccountQuery : Ambiguous external ID gerrit:johndoe for accounts: 1000001, 1000004

[2018-12-05 18:20:55,962] [HTTP-139] ERROR com.google.gerrit.httpd.auth.container.HttpLoginServlet : Unable to authenticate user "johndoe"

com.google.gerrit.server.account.AccountException: Cannot assign external ID "gerrit:mhunjan" to account 1000101; external ID already in use.


Seems that my SAML user got a second user entry in the db.

Before I attempt my hand at fixing this, I'd like an expert opinion.

Thanks,
Mike

Matthew Webber

unread,
Dec 5, 2018, 4:20:44 PM12/5/18
to Repo and Gerrit Discussion

Following the data migration, I stopped my gerrit instance, changed my etc/gerrit.config file to point to the new db instance, and then restarted the gerrit server. the Gerrit service started up with no issues. 

To confirm: you left your Gerrit server running while you dumped the database, and after that you stopped Gerrit?
Did updates/things continue to happen after that dump was taken?
I'm not sure how that would produce the result that you see, but it's worth considering.
Matthew

Mike Lupo

unread,
Dec 5, 2018, 6:33:02 PM12/5/18
to Matthew Webber, Repo and Gerrit Discussion
Hi Matthew.
The gerrit server was completely offline while the dump and migration were in progress. I didn’t want any changes coming in at all during the migration.

Where is the user database stored in 2.14.1? 

Sent from my iPhone
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/repo-discuss/aeaByHZwAko/unsubscribe.
To unsubscribe from this group and all its topics, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mike Lupo

unread,
Dec 5, 2018, 9:15:56 PM12/5/18
to Repo and Gerrit Discussion
In case it helps: here is the entire call stack. Every time this user tries to hit gerrit, this appears in the log, Note that the account number referenced (100109) gets iterated by +1.
and of course my user isn't johndoe. He's a real person in our corporation. Scrubbed. 

I restored back to the original database (thought that'd be all I'd have to do) before any other users could try. Thankfully, all my other users are fine. Only the guy who tried to hit gerrit against the migrated db instance saw an unexpected, "First time user" dialog in Gerrit. Thankfully, he can still push code using his existing SSH keys, he just can't get to the gerrit web UI.

Also gonna post to Stack overflow to cast a wide net. 
RIP Shawn Pearce! Original author of AccountManager.java

com.google.gerrit.server.account.AccountException: Cannot assign external ID "gerrit:johndoe" to account 1000109; external ID already in use.

at com.google.gerrit.server.account.AccountManager.create(AccountManager.java:237)

at com.google.gerrit.server.account.AccountManager.authenticate(AccountManager.java:118)

at com.google.gerrit.httpd.auth.container.HttpLoginServlet.doGet(HttpLoginServlet.java:119)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:286)

at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:276)

at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:181)

at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)

at com.google.gerrit.httpd.raw.StaticModule$PolyGerritFilter.doFilter(StaticModule.java:451)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.GetUserFilter.doFilter(GetUserFilter.java:75)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.RequireSslFilter.doFilter(RequireSslFilter.java:73)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.UniversalWebLoginFilter.doFilter(UniversalWebLoginFilter.java:74)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.RunAsFilter.doFilter(RunAsFilter.java:111)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gwtexpui.server.CacheControlFilter.doFilter(CacheControlFilter.java:70)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.RequestMetricsFilter.doFilter(RequestMetricsFilter.java:57)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:133)

at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:135)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:72)

at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)

at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:120)

at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:135)

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)

at com.thesamet.gerrit.plugins.saml.SamlWebFilter.doFilter(SamlWebFilter.java:157)

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)

at org.eclipse.jetty.server.Server.handle(Server.java:534)

at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)

at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)

at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)

at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)

at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)

at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)

at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)

at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)

at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)

at java.lang.Thread.run(Thread.java:748)


On Wednesday, December 5, 2018 at 1:11:13 PM UTC-5, Mike Lupo wrote:

David Ostrovsky

unread,
Dec 6, 2018, 12:17:43 AM12/6/18
to Repo and Gerrit Discussion


On Thursday, December 6, 2018 at 3:15:56 AM UTC+1, Mike Lupo wrote:
In case it helps: here is the entire call stack. Every time this user tries to hit gerrit, this appears in the log, Note that the account number referenced (100109) gets iterated by +1.
and of course my user isn't johndoe. He's a real person in our corporation. Scrubbed. 

I restored back to the original database (thought that'd be all I'd have to do) before any other users could try. Thankfully, all my other users are fine. Only the guy who tried to hit gerrit against the migrated db instance saw an unexpected, "First time user" dialog in Gerrit. Thankfully, he can still push code using his existing SSH keys, he just can't get to the gerrit web UI.

That indicates, that this problem is not related to database migration to another host.
It seems to be a known issue, see for example this comment how to fix that database
corruption: [1]. I think we still don't know why this corruption happens. I've never migrated
database to another server, but one thing to check is sequences re-initialization.


Mike Lupo

unread,
Dec 6, 2018, 9:02:12 AM12/6/18
to Repo and Gerrit Discussion
Thank You David for your reply.

In the case of the user in the defect you linked, there is a user with account_id 143 that's missing a row in the db (as compared to another user).
In my case, the user has three rows just like everyone else. (we have a third row containing a line for SAML)
Since the external_ids column is specified to contain unique items, I could not re-add this user as account_id 1000004.

Here is what I had to do in order to restore the user. 
1) Utterly wipe out (rm -rf /gerrit) the gerrit repo on the ubuntu host and replace it with the rsync snapshot I took just before I started the migration.
2) Reindex both accounts and changes.  **see note below.
3) Instruct the user to re-try hitting Gerrit. Success this time.

** Note: I cannot reindex changes offline successfully. I see a call stack with: 

ERROR com.google.gerrit.server.index.change.ChangeIndexer : Failed to execute reindex-if-stale-change-7132


anyway...I'm going to try this data migration again. Fingers crossed.



On Wednesday, December 5, 2018 at 1:11:13 PM UTC-5, Mike Lupo wrote:
Reply all
Reply to author
Forward
0 new messages