Go ahead and add this to the logback.xml (i.e. <ART_HOME>/var/etc/artifactory/logback.xml) of the nodes in the cluster where the migration have not taken place so that more verbose logs be outputted. Place it right before the closing </configuration> tag. No restart is needed for the logger to take effect and you will see a log file called artifactory-event-migration.log be generated. Don’t forget to remove this snippet after you have finished troubleshooting so that the logs don’t keep getting outputted.
This will give some insight into if the migration is taking place or some other issue is preventing the migration.
Some logs to look out for:
"start execute events table repo key migration in the first time"
"start execute events table repo key again because its finished unsuccessfully"
"Inserting new migration status record '
"Migration with ID '{}' already exists."
"finish to add {} index on {}"
"successfully finished execute events table repo key migration"
"Migration for '{}' has finished."
The ‘{}’ are placeholders and will contain something else in the logs.
But if you don’t see any of these in the logs there check if you see items like the following.
“number of events that going to be deleted for repo key: ‘{}’ is ‘{}’”
This means that it is undergoing a cleanup job which must be completed before it starts the migration process. This cleanup can take some time and you must wait for this to completed.
<appender name="eventmigration-log" class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>${log.dir}/artifactory-event-migration.log</File>
<rollingPolicy class="org.jfrog.common.logging.logback.rolling.FixedWindowWithDateRollingPolicy">
<FileNamePattern>${log.dir.archived}/artifactory-event-migration.%i.log.gz</FileNamePattern>
<maxIndex>10</maxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<MaxFileSize>25MB</MaxFileSize>
</triggeringPolicy>
<encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
<layout class="org.jfrog.common.logging.logback.layout.BackTracePatternLayout">
<pattern>%date{yyyy-MM-dd'T'HH:mm:ss.SSS, UTC}Z [jfrt ] [%-5p] [%-16X{uber-trace-id}] [%-30.30(%c{3}:%L)] [%-20.20thread] - %m%n</pattern>
</layout>
</encoder>
</appender>
<logger name="org.artifactory.event.migration" additivity="false">
<level value="trace"/>
<appender-ref ref="eventmigration-log"/>
</logger>
<logger name="org.artifactory.storage.db.event.dao.eventTableRepoKeyMigration" additivity="false">
<level value="trace"/>
<appender-ref ref="eventmigration-log"/>
</logger>
<logger name="org.artifactory.storage.db.event.dao.eventTableRepoKeyMigration.EventTableRepoKeyMigrationDao" additivity="false">
<level value="trace"/>
<appender-ref ref="eventmigration-log"/>
</logger>
<logger name="org.artifactory.event.EventsLogCleanUpService" additivity="false">
<level value="trace"/>
<appender-ref ref="eventmigration-log"/>
</logger>
<logger name="org.artifactory.storage.db.event.service" additivity="false">
<level value="trace"/>
<appender-ref ref="eventmigration-log"/>
</logger> This will give some insight into if the migration is taking place or some other issue is preventing the migration.
Some logs to look out for:
"start execute events table repo key migration in the first time"
"start execute events table repo key again because its finished unsuccessfully"
"Inserting new migration status record '
"Migration with ID '{}' already exists."
"finish to add {} index on {}"
"successfully finished execute events table repo key migration"
"Migration for '{}' has finished."
The ‘{}’ are placeholders and will contain something else in the logs.
But if you don’t see any of these in the logs there check if you see items like the following.
“number of events that going to be deleted for repo key: ‘{}’ is ‘{}’”
This means that it is undergoing a cleanup job which must be completed before it starts the migration process. This cleanup can take some time and you must wait for this to completed.