Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Are there chnages to Ambari metadata tables (DDL changes) between Ambari 2.2 to 2.2.2 ?

avatar

We have a migrate script for migrating Ambari metadata from postgres to oracle, for Ambari 2.2. Now we have to migrate Ambari 2.2.2 (from Postgres to Oracle). Will the same script work ? If there are DDL chnages in new Ambari, I might have to update my scripts accordingly. anyone with experience on this please advice.

1 ACCEPTED SOLUTION

avatar
Super Collaborator

Yes, there are most likely changes, especially if your "starting" version is 2.2.0.0 - it kind of depends on which version of Ambari you modeled your script after.

git diff release-2.2.0-rc0 release-2.2.2 Ambari-DDL-Postgres-CREATE.sql

diff --git a/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql b/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
index 2bcfb9a..3a2899e 100644
--- a/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
+++ b/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
@@ -406,6 +406,7 @@ CREATE TABLE hostgroup_component (
   blueprint_name VARCHAR(255) NOT NULL,
   hostgroup_name VARCHAR(255) NOT NULL,
   name VARCHAR(255) NOT NULL,
+  provision_action VARCHAR(255),
   PRIMARY KEY(blueprint_name, hostgroup_name, name));


 CREATE TABLE blueprint_configuration (
@@ -606,8 +607,10 @@ CREATE TABLE topology_host_info (
   id BIGINT NOT NULL,
   group_id BIGINT NOT NULL,
   fqdn VARCHAR(255),
+  host_id BIGINT,
   host_count INTEGER,
   predicate VARCHAR(2048),
+  rack_info VARCHAR(255),
   PRIMARY KEY (id)
 );


@@ -642,6 +645,14 @@ CREATE TABLE topology_logical_task (
   PRIMARY KEY (id)
 );


+-- tasks indices --
+CREATE INDEX idx_stage_request_id ON stage (request_id);
+CREATE INDEX idx_hrc_request_id ON host_role_command (request_id);
+CREATE INDEX idx_hrc_status_role ON host_role_command (status, role);
+CREATE INDEX idx_rsc_request_id ON role_success_criteria (request_id);
+
+
+
 --------altering tables by creating unique constraints----------
 ALTER TABLE clusterconfig ADD CONSTRAINT UQ_config_type_tag UNIQUE (cluster_id, type_name, version_tag);
 ALTER TABLE clusterconfig ADD CONSTRAINT UQ_config_type_version UNIQUE (cluster_id, type_name, version);
@@ -721,6 +732,7 @@ ALTER TABLE widget_layout_user_widget ADD CONSTRAINT FK_widget_id FOREIGN KEY (w
 ALTER TABLE topology_request ADD CONSTRAINT FK_topology_request_cluster_id FOREIGN KEY (cluster_id) REFERENCES clusters(cluster_id);
 ALTER TABLE topology_hostgroup ADD CONSTRAINT FK_hostgroup_req_id FOREIGN KEY (request_id) REFERENCES topology_request(id);
 ALTER TABLE topology_host_info ADD CONSTRAINT FK_hostinfo_group_id FOREIGN KEY (group_id) REFERENCES topology_hostgroup(id);
+ALTER TABLE topology_host_info ADD CONSTRAINT FK_hostinfo_host_id FOREIGN KEY (host_id) REFERENCES hosts(host_id);
 ALTER TABLE topology_logical_request ADD CONSTRAINT FK_logicalreq_req_id FOREIGN KEY (request_id) REFERENCES topology_request(id);
 ALTER TABLE topology_host_request ADD CONSTRAINT FK_hostreq_logicalreq_id FOREIGN KEY (logical_request_id) REFERENCES topology_logical_request(id);
 ALTER TABLE topology_host_request ADD CONSTRAINT FK_hostreq_group_id FOREIGN KEY (group_id) REFERENCES topology_hostgroup(id);
@@ -888,6 +900,7 @@ CREATE TABLE upgrade (
   skip_failures SMALLINT DEFAULT 0 NOT NULL,
   skip_sc_failures SMALLINT DEFAULT 0 NOT NULL,
   downgrade_allowed SMALLINT DEFAULT 1 NOT NULL,
+  suspended SMALLINT DEFAULT 0 NOT NULL,
   PRIMARY KEY (upgrade_id),
   FOREIGN KEY (cluster_id) REFERENCES clusters(cluster_id),
   FOREIGN KEY (request_id) REFERENCES request(request_id)
@@ -1038,7 +1051,7 @@ INSERT INTO adminprivilege (privilege_id, permission_id, resource_id, principal_
   SELECT 1, 1, 1, 1;


 INSERT INTO metainfo (metainfo_key, metainfo_value)
-  SELECT 'version', '${ambariVersion}';
+  SELECT 'version', '${ambariSchemaVersion}';
 COMMIT;

View solution in original post

3 REPLIES 3

avatar
Super Collaborator

Yes, there are most likely changes, especially if your "starting" version is 2.2.0.0 - it kind of depends on which version of Ambari you modeled your script after.

git diff release-2.2.0-rc0 release-2.2.2 Ambari-DDL-Postgres-CREATE.sql

diff --git a/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql b/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
index 2bcfb9a..3a2899e 100644
--- a/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
+++ b/ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql
@@ -406,6 +406,7 @@ CREATE TABLE hostgroup_component (
   blueprint_name VARCHAR(255) NOT NULL,
   hostgroup_name VARCHAR(255) NOT NULL,
   name VARCHAR(255) NOT NULL,
+  provision_action VARCHAR(255),
   PRIMARY KEY(blueprint_name, hostgroup_name, name));


 CREATE TABLE blueprint_configuration (
@@ -606,8 +607,10 @@ CREATE TABLE topology_host_info (
   id BIGINT NOT NULL,
   group_id BIGINT NOT NULL,
   fqdn VARCHAR(255),
+  host_id BIGINT,
   host_count INTEGER,
   predicate VARCHAR(2048),
+  rack_info VARCHAR(255),
   PRIMARY KEY (id)
 );


@@ -642,6 +645,14 @@ CREATE TABLE topology_logical_task (
   PRIMARY KEY (id)
 );


+-- tasks indices --
+CREATE INDEX idx_stage_request_id ON stage (request_id);
+CREATE INDEX idx_hrc_request_id ON host_role_command (request_id);
+CREATE INDEX idx_hrc_status_role ON host_role_command (status, role);
+CREATE INDEX idx_rsc_request_id ON role_success_criteria (request_id);
+
+
+
 --------altering tables by creating unique constraints----------
 ALTER TABLE clusterconfig ADD CONSTRAINT UQ_config_type_tag UNIQUE (cluster_id, type_name, version_tag);
 ALTER TABLE clusterconfig ADD CONSTRAINT UQ_config_type_version UNIQUE (cluster_id, type_name, version);
@@ -721,6 +732,7 @@ ALTER TABLE widget_layout_user_widget ADD CONSTRAINT FK_widget_id FOREIGN KEY (w
 ALTER TABLE topology_request ADD CONSTRAINT FK_topology_request_cluster_id FOREIGN KEY (cluster_id) REFERENCES clusters(cluster_id);
 ALTER TABLE topology_hostgroup ADD CONSTRAINT FK_hostgroup_req_id FOREIGN KEY (request_id) REFERENCES topology_request(id);
 ALTER TABLE topology_host_info ADD CONSTRAINT FK_hostinfo_group_id FOREIGN KEY (group_id) REFERENCES topology_hostgroup(id);
+ALTER TABLE topology_host_info ADD CONSTRAINT FK_hostinfo_host_id FOREIGN KEY (host_id) REFERENCES hosts(host_id);
 ALTER TABLE topology_logical_request ADD CONSTRAINT FK_logicalreq_req_id FOREIGN KEY (request_id) REFERENCES topology_request(id);
 ALTER TABLE topology_host_request ADD CONSTRAINT FK_hostreq_logicalreq_id FOREIGN KEY (logical_request_id) REFERENCES topology_logical_request(id);
 ALTER TABLE topology_host_request ADD CONSTRAINT FK_hostreq_group_id FOREIGN KEY (group_id) REFERENCES topology_hostgroup(id);
@@ -888,6 +900,7 @@ CREATE TABLE upgrade (
   skip_failures SMALLINT DEFAULT 0 NOT NULL,
   skip_sc_failures SMALLINT DEFAULT 0 NOT NULL,
   downgrade_allowed SMALLINT DEFAULT 1 NOT NULL,
+  suspended SMALLINT DEFAULT 0 NOT NULL,
   PRIMARY KEY (upgrade_id),
   FOREIGN KEY (cluster_id) REFERENCES clusters(cluster_id),
   FOREIGN KEY (request_id) REFERENCES request(request_id)
@@ -1038,7 +1051,7 @@ INSERT INTO adminprivilege (privilege_id, permission_id, resource_id, principal_
   SELECT 1, 1, 1, 1;


 INSERT INTO metainfo (metainfo_key, metainfo_value)
-  SELECT 'version', '${ambariVersion}';
+  SELECT 'version', '${ambariSchemaVersion}';
 COMMIT;

avatar

Thanks Jonathan. that helps. my main concern is the addition of new tables or columns to existing tables. your compare shows me there are four tables with column changes. would you agree ?

avatar
Super Collaborator

I think the break down is like this:

  • Changes to tables
    • hostgroup_component (1 added)
    • topology_host_info (2 added)
    • upgrade (1 added)
  • New Indexes
    • 4 added
  • Referential Integrity
    • FK_hostinfo_host_id constraint added