<div dir="ltr"><div><div>Hi everybody,</div><div><br></div><div>the Analytics team needs to make some changes to the current configuration and deployment of the Analytics databases. Before starting a little refresh to be on the same page:</div><span class="gmail-im"><div><br></div><div>- db1046 - eventlogging master database</div><div>- db1047 - also known as analytics-slave.eqiad.wmnet - replicates via mysql s1/s2 and the log database (on db1046) using a custom replication script.</div><div>- dbstore1002 - also known as analytics-store.eqiad.wmnet and x1-analytics-slave.eqiad.wmnet - replicates most of the S shards and X1 via mysql, and the log database using a custom replication script.</div><div>- db1108 (brand new host) - replicates the log database using a custom replication script.</div><div><br></div><div>We have been suffering during the past months some space and performance issues on dbstore1002 (<a href="https://phabricator.wikimedia.org/T168303" target="_blank">https://phabricator.<wbr>wikimedia.org/T168303</a>), so we came up with the following plan:</div><div><br></div><div>- db1108, a brand new host with SSD disks, replaces db1047 and becomes the CNAME of analytics-slave.eqiad.wmnet. This new host will be a replica of the log database only, no other database will be replicated.</div><div>- dbstore1002 will loose the support of the log database, that will be dropped from the host.</div></span><div>- db1047 will eventually be decommissioned (after backing up data and alert people beforehand - T156844).</div><div><br></div><div>This will allow us to:</div><div>1) Reduce the load on dbstore1002 and free a lot of space on the host.</div><div>2) Offer a more performant way to query eventlogging analytics data.</div><div>3) Reduce the current performance issues that we have been experiencing while trying to sanitize/purge old event-logging data (<a href="https://phabricator.wikimedia.org/T156933" target="_blank">https://phabricator.<wbr>wikimedia.org/T156933</a>) </div><div><br></div><div>The plan is the following:</div><div><br></div><div>- November 13th: the analytics-slave CNAME moves from db1047 to db1108</div><div>- November 20th: the log database will be dropped from dbstore1002/analytics-store together with the event-logging replication script</div><span class="gmail-im"><div>- December 4th: shutdown of db1047 (prior backup of non-log database tables)</div><div><br></div><div>More info in <a href="https://phabricator.wikimedia.org/T156844" target="_blank">https://phabricator.wikimedia.<wbr>org/T156844</a></div><div><br></div></span><div>To summarize what will change from the users perspective:</div><div><br></div><div>- dbstore1002 (analytics-store) will offer all the S/X shards replication (wikis) and all the databases like staging that everybody is used to work with. It will only loose the support of the log database.</div><div>- db1108 will offer the log database replication and a staging database.</div><div>- the db1047's (analytics-slave) staging database will be moved or copied with a different name (like staging_db1047) to dbstore1002.</div><div><br></div><div>Please let us know in the task your opinion in T156844, we'd love to hear some feedback before proceeding, especially about extra requirements that we haven't thought of.</div><div class="gmail-yj6qo gmail-ajU" style="margin:2px 0px 0px"><div id="gmail-:3uh" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><div class="gmail-adL"><span class="gmail-im"><div><br></div><div>Thanks!</div><div><br></div><div>Luca (on behalf of the Analytics team)</div><div><br></div></span></div></div><div class="gmail-adL"><div class="gmail-adm" style="font-size:12.8px"></div><div class="gmail-im" style="font-size:12.8px"></div></div></div>