Fail to start sentry service with external database

[#1]

Hi all,

on cloudera manager 5.7.1 i have use this guide ( http://www.cloudera.com/documentation/enterprise/latest/topics/sg_sentry_service_install.html#concep... ) to install Sentry Service.

Before to install service i have create an external MySql database with this commands:

mysql> create database sentry DEFAULT CHARACTER SET utf8;
Query OK, 1 row affected (0.00 sec)

mysql> grant all on sentry.* TO 'sentry'@'%' IDENTIFIED BY 'sentry_password';
Query OK, 0 rows affected (0.00 sec)

When i try to start sentry service i received this error:

exec /opt/cloudera/parcels/CDH-5.7.1-1.cdh5.7.1.p0.11/lib/sentry/bin/sentry --command service --log4jConf /var/run/cloudera-scm-agent/process/2713-sentry-SENTRY_SERVER/sentry-log4j.properties -conffile /var/run/cloudera-scm-agent/process/2713-sentry-SENTRY_SERVER/sentry-site.xml
Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.Exception: Error starting server
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at org.apache.sentry.service.thrift.SentryService.waitOnFuture(SentryService.java:312)
	at org.apache.sentry.service.thrift.SentryService$CommandImpl.run(SentryService.java:398)
	at org.apache.sentry.SentryMain.main(SentryMain.java:114)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
	at org.apache.hadoop.util.RunJar.main(RunJar.java:136)
Caused by: java.lang.Exception: Error starting server
	at org.apache.sentry.service.thrift.SentryService.call(SentryService.java:172)
	at org.apache.sentry.service.thrift.SentryService.call(SentryService.java:72)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Could not create org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessorFactory
	at org.apache.sentry.service.thrift.SentryService.runServer(SentryService.java:207)
	at org.apache.sentry.service.thrift.SentryService.call(SentryService.java:168)
	... 5 more
Caused by: org.apache.sentry.provider.db.SentryNoSuchObjectException: No matching version found
	at org.apache.sentry.provider.db.service.persistent.SentryStore.getMSentryVersion(SentryStore.java:1453)
	at org.apache.sentry.provider.db.service.persistent.SentryStore.getSentryVersion(SentryStore.java:1405)
	at org.apache.sentry.provider.db.service.persistent.SentryStore.verifySentryStoreSchema(SentryStore.java:196)
	at org.apache.sentry.provider.db.service.persistent.SentryStore.<init>(SentryStore.java:176)
	at org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessor.<init>(SentryPolicyStoreProcessor.java:103)
	at org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessorFactory.register(SentryPolicyStoreProcessorFactory.java:31)
	at org.apache.sentry.service.thrift.SentryService.runServer(SentryService.java:201)
	... 6 more

Do yuo have any suggestion?

Thanks, Simone

[#2 · Accepted solution]

I have solved adding this value into sentry-site.xml:

<property><name>sentry.verify.schema.version</name><value> false</value><description> value: true, false true Sentry store will verify the schema version in backed DB with expected version in jar. The service won't start if there's a mismatch </description></property>

[#3]

Mind walking me through how you made this change via Cloudera Manager? Don't think I can edit the xml file directly. Thanks

[#4]

Resolved, by deleting all tables in sentry database in MySQL and then recreating them from Cloudera Manager, and this time by logging into database as root instead of cm user.