Setting up a Separate Dedicated DB Server - Optional

To improve the performance and expand the functionality of environments with a large number of assets, a separate dedicated database server should be set up to manage the Venture database, which is the name the Xinet team has given to the database used to store ancillary information about assets, such as low resolution previews of images/videos, annotations, metadata, and file IDs for linking. As an Administrator, install Xinet on your dedicated database server, obtain a separate Venture-only license, and migrate the Venture database from the main Xinet Administration server to your dedicated db server. Instructions are provided below.

Once Xinet is licensed on your Dedicated DB Server, a limited number of Administration tabs specific to the Venture database are available. For details on the options available in this view, see Xinet Statistics and Database Operations — the Database, Admin subtab.

Note: The database daemon (dblogd(8)) will run on the main Xinet Server, not on the Dedicated DB Server, so the Dedicated DB Server cannot run independently of the Xinet Administration server.

To install and license Xinet on a Dedicated DB Server:

1.	Install the Xinet Administration software on your Dedicated DB Server

For more information, seeInstall Xinet Server on a Macintosh Server (first time or upgrade).

2.	Launch Xinet on your Dedicated DB Server and click License > License > Send License Request.

3.	Fill out the form to submit a request for a Venture license for your Dedicated DB Server.

Note: Remember to place a check mark in the Database Server only field to indicate a Venture license is required.

For more information, see Licensing Software.

Next, as an Administrator, start the database manager (dbmgr) on your Dedicated DB Server and migrate the Venture database from your main Xinet Administration server.

To migrate the database to your Dedicated DB Server:

1.	On your Dedicated DB Server, open a command-line and type the following command to run the database manager:

dbmgr -mysqldonly <IP address or hostname of the Xinet Administration Server>

2.	On your main Xinet Administration server, stop the database.

•	Click Database > Admin > Settings and in the Database Server options click Stop Database.

IMPORTANT: If this is a new Xinet installation on both the Xinet server and your dedicated database server, DO NOT STOP the database.

3.	Migrate the latest database from the main Xinet Administration server to your Dedicated DB Server.

•	Copy a ‘Full’ backup from your Xinet Administration Server to your Dedicated DB Server.

Establish where and when the latest backup is located. On the Xinet Administration view, click Database > Admin > Backup to review the details. Click Full Backup to generate a backup and copy it to your Dedicated DB Server.

Next, configure the main Xinet Administration server to point to the database on your Dedicated DB Server.

To configure the Venture DB location on the main Xinet server:

•	On the Xinet Administration server, open a command-line and type the following:

# /usr/etc/venture/bin/dbmgr -remotemysqld <IP address or host name of the Dedicated DB Server>

Note: For an environment where Xinet has been installed previously, some records may not have been transferred at the time of migration to the Venture database to your Dedicated DB Server. To resolve this issue, run any of the following programs on your Dedicated DB Server:

•	Run the listdir program to verify if the contents displayed in the Portal browser are up-to-date in the Venture database.

•	Run the database daemon (dblogd(8)) to stop and restart the database. Once restarted, the database daemon checks for changes and updates the Venture database.

•	Run the program syncvoltodb with no flags to manually synchronize file information in the Venture database.

For more information, see Database synchronization and Command-line manual pages.

 

Troubleshooting information:

FAQ	Explanation
Can the Venture database migration be done while the database is ingesting data?	Only if you are copying a Full Backup from the Xinet Administration server to ensure you’re using a static version of the database. If you are copying the database tables, ensure that the database is not running before copying your tables.
What happens when the webbdlogs is running on the Xinet Administration Server while migrating the Venture database?	The webdblog continues to be processed by the Database Daemon (dblogd(8). Once the dbmgr -remotemysql command is run, the webdblog entries are processed and entered into the database on the Dedicated DB Server instead of the main Xinet Administration Server.
Should the database server be built from scratch?	Only if you are installing Xinet for the first time on both the Xinet Administration Server and the Dedicated DB Server. If you are working with a previously installed Xinet Venture database, the data will begin to ingest on the DATABASE server once the migration is completed.
How do you remove the database server?	In the Xinet Administration Server, stop the database to prevent further processing. Contact Xinet Support for assistance.
Why isn’t mysqld running on the Xinet Administration Server?	After the Venture database migration is completed, mysgld will only run on the database server.
Is the Solr database also moved in the migration to the database server?	No, the Solr database will continue to run on the main Xinet Administration Server. It is a separate database used to store Solr search tokens for servers with Solr Search enabled.
How can I lookup the DB server using a command-line from the Xinet Administration server (master)?	Open the my.cnf and locate the following code:   [client] host=<IP Addr> | <hostname> protocol=tcp socket=/usr/etc/venture/var/mysql.sock   This information is also found in the dblogd.conf file. [Options] Mysql Host=<IP Addr> | <hostname> | local

Disabling the Dedicated DB Server

You can disable the Dedicated DB Server at any time and migrate the database back to the main Xinet Administration Server.

To disable the dedicated database server:

1.	Send a notification email out to your Portal users, informing them that the server is undergoing maintenance.

2.	Stop the database on your dedicated DB server.

Click Database > Admin > Settings and in the Database Server options, click Stop Database.

3.	Restore the default Venture database settings.

On the Xinet Administration Server, run the following commands from a command-line:

cd /usr/etc/venture/bin/

mv no_safe_mysqld safe_mysqld

ln -s safe_mysqld mysqld_safe

4.	Edit the Xinet Venture Database settings.

a. On the Xinet Administration Server, in a command-line, change directory to /usr/etc/venture/var/ and open my.cnf

b. Remove the "host" and "protocol" lines from the [client] section.

c. Copy the "socket" line from the [mysqld] section to the [client] section.

d. Save the my.cnf file.

5.	Remove the pointer to the Mysql Host on the Dedicated DB Server.

a. On the Xinet Administration Server, open /var/adm/webnative/dblogd.conf.

Windows: c:/Program Files (x86)/Xinet/WebNative/Admin/dblogd.conf

Unix: /var/adm/webnative/dblogd.conf

b. Remove the Mysql Host line.

c. Save the dblogd.conf file.

6.	Copy the backup database file from the Dedicated DB Server to the Venture database on the Xinet Administrator Server.

a. On the Administration Server, first create a new folder to put the backup database file from your Dedicated DB Server. Click Databases > Admin > Backup and click Edit for the Backup Location. Click Create Folder, specify a new folder name, and click Set Directory.

Note: It is best practice to always create a new folder to store your backup database file.

b. Copy the backup database file created in Step 3. from the Dedicated DB Server to the Xinet Administration Server putting it in the location created in Step a. The backup file uses the following naming convention: wnv_fullbackup.<DATE>.

c. Restore the database on the Xinet Administration Server. With each full backup, Xinet includes a restoration script. In a command-line, on your Xinet Administration Server, run the following:

# RESTORE_FULL
The database will start automatically when this script is run.

For more information, see Backing up and restoring data.

Note: You can create a new database, on the Administration Server, by running the /usr/etc/webnative/configure.apache script which extracts information from your stored assets. Note, this will take some time to complete if you have a large number of assets in your database.