Support #17295
move dbu tables from offline_dev to offline
80%
Description
There are four tables in use in the offline_dev database,
which we should move to the offline database
before the Aug 8 move to Mariadb.
We will then rename offline_dev to offline_int
DBUDAQFILESUMMARY
DBUDAQFILESUMMARYVLD
DBURUNSUMMARY
DBURUNSUMMARYVLD
These are written by the predator scrips on minos-data,
and read by various production management scripts.
This Issue will track details of the move.
History
#1 Updated by Arthur Kreymer about 2 years ago
Overview :
- Plan the table copy, to establish timing.
This will probably take a few minutes, as the tables are under 2 GB in size.
- Test the copy in development ( ifdb04 )
DBAs -
- Prepare and test revised predator scripts with the development server.
kreymer -see below, ready to test 08/01
- Prepare and test revised productions scripts with the development server.
- Set a schedule ( Minerva )
- Suspend predator during the the table copy
kreymer -
- Copy the tables
DBAs
- Deploy revised predator scripts
kreymer
- Deploy revised production scripts
#2 Updated by Arthur Kreymer about 2 years ago
- Status changed from New to Work in progress
- % Done changed from 10 to 20
I set up a dbu test area /minos/app/users/mindata/maint/predator.
testdbu is a sample test script there.
I tested dbu on file /pnfs/minos/fardet_data/2005-04/F00031300_0000.mdaq.root
Tests were done as mindata@minos-data as follows- minos-db1
- ifdb04 ( Mysql development )
- mariadb-dev
- reduced the database connection list from test,offline,offline_dev to just offline_dev
I am ready to test the DBU tables copied to offline, in the development servers.
Waiting for that copy.
#3 Updated by Arthur Kreymer about 2 years ago
I tried running dbu using the copy of tables in mariadb-dev offline.
The program fails with a message like
Caching new results: ResultKey: Table: row: No vrecs
See the script and log in /minos/app/users/mindata/maint/predator
testdbu - uses mariadb-dev offline_dev, see mariadb-dev-devonly.log
testdbu-off - uses mariadb-dev offline, see mariadb-dev-offline.log
#4 Updated by Arthur Kreymer about 2 years ago
It appears that we need to copy two more tables from offline_dev to offline.
DBUDAQCONFIGFILESTEXT
DBUDAQCONFIGFILESTEXTVLD
It appears that these may have been modified 2017/07/28
We need to find out what is writing these.
SELECT UPDATE_TIME, TABLE_SCHEMA, TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = 'offline_dev' ORDER BY UPDATE_TIME ASC, TABLE_SCHEMA, TABLE_NAME; +---------------------+--------------+------------------------------------+ | UPDATE_TIME | TABLE_SCHEMA | TABLE_NAME | +---------------------+--------------+------------------------------------+ | 2017-03-15 13:21:02 | offline_dev | BEAMMONSWICMASK | | 2017-03-15 13:21:05 | offline_dev | BEAMMONSWICREL | ... | 2017-04-20 17:16:16 | offline_dev | PULSERRAWDRIFTF | | 2017-07-28 11:10:05 | offline_dev | DBUDAQCONFIGFILESTEXT | | 2017-07-28 11:10:05 | offline_dev | DBUDAQCONFIGFILESTEXTVLD | | 2017-07-28 11:10:05 | offline_dev | LOCALSEQNO | | 2017-08-01 23:09:09 | offline_dev | DBUDAQFILESUMMARY | | 2017-08-01 23:09:09 | offline_dev | DBUDAQFILESUMMARYVLD | | 2017-08-01 23:09:17 | offline_dev | DBURUNSUMMARY | | 2017-08-01 23:09:17 | offline_dev | DBURUNSUMMARYVLD | +---------------------+--------------+------------------------------------+ 144 rows in set (0.00 sec)
#5 Updated by Arthur Kreymer about 2 years ago
After Svetlana copied DBUDAQCONFIGFILESTEXT and DBUDAQCONFIGFILESTEXTVLD
from offline_dev to offline in mariadb_dev,
the testdb-off scripts runs
and produces F00031300_0000.sam.py SAM metadata files.
As Robert suggested, these DBUDAQCONFIGFILES tables are not recently changed
select INSERTDATE from DBUDAQCONFIGFILESTEXTVLD order by INSERTDATE desc limit 10; +---------------------+ | INSERTDATE | +---------------------+ | 2017-05-25 22:08:34 | | 2017-05-24 18:10:16 | | 2017-05-18 18:12:54 | | 2017-05-18 18:12:21 | | 2017-05-16 02:08:25 | | 2017-05-16 02:07:31 | | 2017-05-16 00:06:30 | | 2017-05-14 22:06:32 | | 2017-05-10 22:06:28 | | 2017-05-06 00:11:55 | +---------------------+
But we are missing some database messages at job end
which are normally there running with offline_dev :
CommitDbuRunSummary(): DbuRunSummary Far Run 31300 LastSubRun 0 RunType va-calibrate (0x101)
{2005-04-25 16:36:07.000000000Z} {2005-04-25 16:36:07.621514000Z}
Snarls 0 (0) NonSnarls 3 (11) [MISMATCH]
TermCode 1 Errors 0 TimeFrames 0 Dropped 0 Consistency 0x1
ConfigFilesText:
DbuDaqConfigFilesText SeqNo 1275 MD5 "814976c91a4ca64b9b8cc5b93b488c77"
Text [actual text suppressed]
DbuDaqFileModule::EndJob()
Delete DbiStatement
DatabaseInterface shutdown not requested
#6 Updated by Arthur Kreymer about 2 years ago
- % Done changed from 20 to 80
Good news -
I found the defect in my earlier dbu tests.
The dbu_sampy.C script needed to be updated to specify offline.
The new test version is dbu_sampy_off.C
Bad news -
Time is too short to test this and deploy to production
before tomorrow's Mariadb upgrade.
I will continue to test on mariadb-dev.
DBA's have already moved the other offline_dev tables to offline_int on mariadb-prd
I propose that we :- Copy the six DBU tables + LOCALSEQNO to mariadb production offline_dev
tomorrow during Mariadb migration - Copy the six DBU tables + LOCALSEQNO from offline_dev to offline
next Monday Aug 14, coordinated with dbu client changes - Drop the unused offline_dev database a week later, Aug 21
#7 Updated by Arthur Kreymer about 2 years ago
Date: Mon, 7 Aug 2017 20:21:27 +0000
From: Robert W Hatcher <rhatcher@fnal.gov>
To: Arthur E Kreymer <kreymer@fnal.gov>
Subject: Automatic reply: FW: [MINOS - Support #17295] move dbu tables from offline_dev to offline
I am currently away on vacation through 2017-08-21.
I will check my e-mail on occasion;
any but the very most urgent of issues will be unlikely to get a response until my return.
-robert