1RT-SERIALIZER(1)      User Contributed Perl Documentation     RT-SERIALIZER(1)
2
3
4

NAME

6       rt-serializer - Serialize an RT database to disk
7

SYNOPSIS

9           rt-validator --check && rt-serializer
10
11       This script is used to write out the entire RT database to disk, for
12       later import into a different RT instance.  It requires that the data
13       in the database be self-consistent, in order to do so; please make sure
14       that the database being exported passes validation by rt-validator
15       before attempting to use "rt-serializer".
16
17       While running, it will attempt to estimate the number of remaining
18       objects to be serialized; these estimates are pessimistic, and will be
19       incorrect if "--no-users", "--no-groups", or "--no-tickets" are used.
20
21       If the controlling terminal is large enough (more than 25 columns high)
22       and the "gnuplot" program is installed, it will also show a textual
23       graph of the queue size over time.
24
25   OPTIONS
26       --directory name
27           The name of the output directory to write data files to, which
28           should not exist yet; it is a fatal error if it does.  Defaults to
29           "./$Organization:Date/", where $Organization is as set in
30           RT_SiteConfig.pm, and Date is today's date.
31
32       --force
33           Remove the output directory before starting.
34
35       --size megabytes
36           By default, "rt-serializer" chunks its output into data files which
37           are around 32Mb in size; this option is used to set a different
38           threshold size, in megabytes.  Note that this is the threshold
39           after which it rotates to writing a new file, and is as such the
40           lower bound on the size of each output file.
41
42       --no-users
43           By default, all privileged users are serialized; passing
44           "--no-users" limits it to only those users which are referenced by
45           serialized tickets and history, and are thus necessary for internal
46           consistency.
47
48       --no-groups
49           By default, all groups are serialized; passing "--no-groups" limits
50           it to only system-internal groups, which are needed for internal
51           consistency.
52
53       --no-assets
54           By default, all assets are serialized; passing "--no-assets" skips
55           assets during serialization.
56
57       --no-disabled
58           By default, all queues, custom fields, etc, including disabled
59           ones, are serialized; passing "--no-disabled" skips such disabled
60           records during serialization.
61
62       --no-deleted
63           By default, all tickets and assets, including deleted ones, are
64           serialized; passing "--no-deleted" skips deleted tickets and assets
65           during serialization.
66
67       --scrips
68           No scrips or templates are serialized by default; this option
69           forces all scrips and templates to be serialized.
70
71       --acls
72           No ACLs are serialized by default; this option forces all ACLs to
73           be serialized.
74
75       --no-tickets
76           Skip serialization of all ticket data.
77
78       --limit-queues
79           Takes a list of queue IDs or names separated by commas. When
80           provided, only that set of queues (and the tickets in them) will be
81           serialized.
82
83       --limit-cfs
84           Takes a list of custom field IDs or names separated by commas. When
85           provided, only that set of custom fields will be serialized.
86
87       --hyperlink-unmigrated
88           Replace links to local records which are not being migrated with
89           hyperlinks.  The hyperlinks will use the serializing RT's
90           configured URL.
91
92           Without this option, such links are instead dropped, and
93           transactions which had updated such links will be replaced with an
94           explanatory message.
95
96       --no-transactions
97           Skip serialization of all transactions on any records (not just
98           tickets).
99
100       --clone
101           Serializes your entire database, creating a clone.  This option
102           should be used if you want to migrate your RT database from one
103           database type to another (e.g.  MySQL to Postgres).  It is an error
104           to combine "--clone" with any option that limits object types
105           serialized.  No dependency walking is performed when cloning.
106           "rt-importer" will detect that your serialized data set was
107           generated by a clone.
108
109       --incremental
110           Will generate an incremenal serialized dataset using the data
111           stored in your IncrementalRecords database table.  This assumes
112           that you have created that table and run RT using the
113           Record_Local.pm shim as documented in "docs/incremental-export/".
114
115       --gc n
116           Adjust how often the garbage collection sweep is done; lower
117           numbers are more frequent.  See "GARBAGE COLLECTION".
118
119       --page n
120           Adjust how many rows are pulled from the database in a single
121           query.  Disable paging by setting this to 0.  Defaults to 100.
122
123           Keep in mind that rows from RT's Attachments table are the limiting
124           factor when determining page size.  You should likely be aiming for
125           60-75% of your total memory on an otherwise unloaded box.
126
127       --quiet
128           Do not show graphical progress UI.
129
130       --verbose
131           Do not show graphical progress UI, but rather log was each row is
132           written out.
133

GARBAGE COLLECTION

135       "rt-serializer" maintains a priority queue of objects to serialize, or
136       searches which may result in objects to serialize.  When inserting into
137       this queue, it does no checking if the object in question is already in
138       the queue, or if the search will contain any results.  These checks are
139       done when the object reaches the front of the queue, or during periodic
140       garbage collection.
141
142       During periodic garbage collection, the entire queue is swept for
143       objects which have already been serialized, occur more than once in the
144       queue, and searches which contain no results in the database.  This is
145       done to reduce the memory footprint of the serialization process, and
146       is triggered when enough new objects have been placed in the queue.
147       This parameter is tunable via the "--gc" parameter, which defaults to
148       running garbage collection every 5,000 objects inserted into the queue;
149       smaller numbers will result in more frequent garbage collection.
150
151       The default of 5,000 is roughly tuned based on a database with several
152       thousand tickets, but optimal values will vary wildly depending on
153       database configuration and size.  Values as low as 25 have provided
154       speedups with smaller databases; if speed is a factor, experimenting
155       with different "--gc" values may be helpful.  Note that there are
156       significant boundary condition changes in serialization rate, as the
157       queue empties and fills, causing the time estimates to be rather
158       imprecise near the start and end of the process.
159
160       Setting "--gc" to 0 turns off all garbage collection.  Be aware that
161       this will bloat the memory usage of the serializer.  Any negative value
162       for "--gc" turns off periodic garbage collection and instead objects
163       already serialized or in the queue are checked for at the time they
164       would be inserted.
165
166
167
168perl v5.34.0                      2022-03-01                  RT-SERIALIZER(1)
Impressum