[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