Layer7 API Management

Hi, We are migrating our  gateway from one server to another. To sync up the all databases data, we exported all databases dump from on premise server and imported into cloud server. Tried to start gateway and then observed gateway is not starting.

Providing ssg log below. 2019-05-16T07:02:06.142+0200 INFO 1 com.l7tech.server.util.GatewayDbVersionChecker: Gateway version: 9.4.00 2019-05-16T07:02:06.145+0200 INFO 1 com.l7tech.server.util.GatewayDbVersionChecker: Database version: 9.4.00 2019-05-16T07:02:11.324+0200 INFO 1 com.l7tech.security.prov.defaultprov.DefaultJceProviderEngine: Initializing Bouncy Castle library in Non-FIPS mode 2019-05-16T07:02:13.153+0200 INFO 1 com.l7tech.server.service.ServiceWsdlImportChecker: Checking WSDL imports for SOAP services. 2019-05-16T07:02:17.705+0200 INFO 1 com.l7tech.server.transport.SsgConnectorManagerImpl: Default HTTP port: 8080 2019-05-16T07:02:17.715+0200 INFO 1 com.l7tech.server.transport.SsgConnectorManagerImpl: Default HTTPS port: 8443 2019-05-16T07:02:18.032+0200 INFO 1 com.l7tech.server.log.SinkManager: Redirecting logging to configured log sinks.

There is KB article to resolve "Redirecting logging to configured log sinks" issue, there is no syslog configuration in our API Gateway. https://comm.support.ca.com/kb/gateway-would-not-start/kb000094895#

Could someone help us to find root cause and resolution.

Below are the commands that we did execute for migration:

mysqldump -uroot -p ssg | gzip > /opt/SecureSpan/APIDevSSG14052019781.sql.gz
scp /opt/SecureSpan/APIDevSSG14052019781.sql.gz root@destserver:/tmp
gzip -d /tmp/APIDevSSG14052019781.sql.gz
mysql -uroot -p ssg < /tmp/APIDevSSG14052019781.sql

Thanks,

Manasa

Hi,

most likely gateway is trying to redirect startup logs using audit sink policy and cannot continue. You need to delete audit sink policies to start gateway: 

Goto database and delete audit sink and lookup policies:

delete from ssg.cluster_properties where propkey ='audit.sink.alwaysSaveInternal' or propkey = 'audit.sink.policy.guid' or propkey='audit.lookup.policy.guid'

Hi,

I believe you had opened up a support issue pertaining to this as well.

It was advised to not take a mysqldump from one gateway and try to import that to a completely

different gateway server.

Instead, look to use the supported method of ssgbackup/ssgmigrate.

Using this approach was successful and you were able to import the db to the

desired gateway.

Thanks,

Daren