Stored persistent ID and migration to 3.2
Simon Lundström
simlu at su.se
Fri Nov 20 09:50:22 EST 2015
Hi!
I've just started the upgrade to 3.2 and fixing WARNs as I go. After
migrating persistent ID store to the new syntax and fixing the SQL
schema (we actually had one dupe user, but it had the same data so that
was pretty lucky) I noticed this in the logs:
2015-11-20 15:22:12,305 - WARN [net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:782] - Stored Id Store: Duplicate insert failed as required with SQL State '23000', ensure this value is configured as a retryable error
2015-11-20 15:22:12,313 - INFO [net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx:467] - Stored Id Store: Data source successfully verified
Is that something you need to fix or for us deployers to configure?
We're using MySQL 5.1.73 from Ubuntu if that matters.
One question regarding the instructions in PID docs [1] though, it says
"Dump the existing table, *reordering the data in the select statement*,
and then load the data back into the recreated table." (emphasis mine).
It can be something specific to another RDBMS but in a MySQL dump there
isn't any SELECT-statement in a dump. IIRC neither is there one in one
from Postgres? Maybe it can be done more generic?
And to the real question; why would it need to be rearranged? Because
the Stored ID DDL reorders them? Why does it reorder them? Seems like a
lot of work for deployers for nothing worth?
I just added the PRIMARY KEY triplet and removed our other indexes
(which probably were wrong anyway) and it worked.
Have a great weekend!
BR,
- Simon
1, https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration#PersistentNameIDGenerationConfiguration-MigratingfromOlderVersions
____________________________________
Simon Lundström
Section for Infrastructure
IT Services
Stockholm University
SE-106 91 Stockholm, Sweden
www.su.se/english/staff-info/it
More information about the users
mailing list