[Bucardo-general] Odd 'inconsistency' after one-time-copy

Paul Theodoropoulos paul at anastrophe.com
Tue Jul 23 21:49:21 UTC 2013


Thanks Mitchell.

A simple count shows the same number of rows on both. I found some more 
'advanced' count statements on the net, which did show minor 
differences, but none that would explain inflation of the disk usage on 
the slave. That said - disk usage is not typically a meaningful measure 
of a database's consistency - that much I do realize. So this could just 
be a byproduct of trigger-based transfer of data to a blank db - I dunno 
(obligatory /not a pgdba from me).  I ran a 'vacuum full' but there was 
no change in space consumed.

A minor mystery, likely not important.

On 7/23/13 2:38 PM, Mitchell Perilstein wrote:
> Are there actually rows missing if you do count(*) from db's on both 
> sides?
>
> I'm wondering if pg_database_size() is measuring allocated space, 
> including some padding rows perhaps.  If there is nothing missing, 
> perhaps the copy might have populated the target db less randomly than 
> the source db was created, in which case a vacuum and/or reindex might 
> bring them into line?  (/not a pgdba)
>
>
> On 07/23/2013 05:29 PM, Paul Theodoropoulos wrote:
>> I'm setting up bucardo for the first time. We have an existing 
>> database, and I'm setting up a slave to become another master. I've 
>> written a fairly detailed shell script to perform the steps 
>> programmatically for consistency in deployment.  There are only three 
>> databases in play here.
>>
>> After the one-time-copy, I issue the following boilerplate query to 
>> see the sizes of the db's (cadged from the 'net):
>> SELECT d.datname AS Name,  pg_catalog.pg_get_userbyid(d.datdba) AS 
>> Owner,
>>     CASE WHEN pg_catalog.has_database_privilege(d.datname, 'CONNECT')
>>         THEN 
>> pg_catalog.pg_size_pretty(pg_catalog.pg_database_size(d.datname))
>>         ELSE 'No Access'
>>     END AS Size
>> FROM pg_catalog.pg_database d
>>     ORDER BY
>>     CASE WHEN pg_catalog.has_database_privilege(d.datname, 'CONNECT')
>>         THEN pg_catalog.pg_database_size(d.datname)
>>         ELSE NULL
>>     END DESC -- nulls first
>>     LIMIT 20;
>>
>> When I run it on the existing master, I get the following:
>>           name           |  owner   |  size
>> --------------------------+----------+---------
>>  db-1                     | postgres | 696 MB
>>  db-2                     | postgres | 244 MB
>>  db-3                     | postgres | 44 MB
>>  bucardo                  | bucardo  | 7174 kB
>>  postgres                 | postgres | 5510 kB
>>  template1                | postgres | 5510 kB
>>  template0                | postgres | 5408 kB
>> (7 rows)
>>
>> When I run it on the server that has received the one-time-copy, I 
>> get this:
>>            name           |  owner   |  size
>> --------------------------+----------+---------
>>  db-1                     | postgres | 723 MB
>>  db-2                     | postgres | 325 MB
>>  db-3                     | postgres | 32 MB
>>  bucardo                  | bucardo  | 6694 kB
>>  postgres                 | postgres | 5518 kB
>>  template1                | postgres | 5510 kB
>>  template0                | postgres | 5408 kB
>> (7 rows)
>>
>> I'm by no means a postgresql dba, I'm merely the SA trying to get 
>> this working. But I'm puzzled as to how the receiving databases would 
>> be *larger* than the source.  Am I missing something very basic here, 
>> or is there a problem?
>>
>
>
> Confidentiality Notice: This e-mail (including any attachments) is 
> intended only for the recipients named above. It may contain 
> confidential or privileged information and should not be read, copied 
> or otherwise used by any other person. If you are not a named 
> recipient, please notify the sender of that fact and delete the e-mail 
> from your system.
>
>

-- 
Paul Theodoropoulos
www.anastrophe.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20130723/894b29d0/attachment.html>


More information about the Bucardo-general mailing list